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1  Introduction 


lliis  document  is  the  final  technical  report  for  the  Boeing  Composite  Routing  program  as  part  of  the  Naval 
Battlefoice  Network  (NBN)  program,  a  subset  of  the  ONR  Knowledge  Superiority  and  Assurance  (KSA)  Future 
Naxa!  Capability  (FNC)  program.  Figure  1-1  summarizes  the  program  schedule  and  recent  program  deliverables  for 
thi.s  contract. 


Apr  02 


Oct  02 


May  03 

ITP  DP  ID 


Sep  03 
FDP  I'D 


Reqts.  Simulation  implementation  Integration/Test  Expt./Demo. 


Technology  transition 


Key: 

ITP;  Integration  and  Test  Plan  (not  CDRI-)  February  2003 
DP;  Draft  Demonstration  Plan  (not  CDRL)  April  2003 
ID:  Interim  Demonstration  (not  CDRL)  15  May  2003 
FDP;  Final  Demonstration  Plan  (CDRL)  30  July  2003 
FD;  Final  Demonstration  (CDRL)  18  September  2003 

Figure  I  I  Kty  recen!  program  mtlcfionex/or  Boeing  Composite  Routing 

1  his  divunumi  supplements  the  three  previous  techrical  reports  ani  tlie  software  deliverables  submitted  under  this 
contract  1  1 J 

•  Naval  Hutileforce  Networking  Requirements  Report: 

•  Protixo!  F  \  aluation  Report; 

•  1  mal  tVmonsirali  m  Finn:  and 

•  Routing  Prot<x<vl  Source  Code  and  l)i>cumeniation 

In  particular,  this  document  desenbes  the  software  implementation  of  a  modified  OSPFv2  {5J  routing  daemon  for 
l.mux.  ilic  laboratory  testing  results  of  ilic-proioiype  imptemenulion.  and  the  results  of  the  final  program 
denH'nsiraiion  in  San  Diego  on  September  IH,  2003 

I  he  reniaifidiT  of  this  cU«cument  organi/rd  as  follows 

•  Section  ?  listc  applicable  referem e  dsKuments; 

•  Section  ^  summarizes  progr.mt  deliverables 

•  Sivtion  ■<  procidc'c  on  ovcn-icw  of  the  M'fiwarc  implementation: 

•  Section  S  dcHfibes  test  and  measureincnt  techniques,  including  perfomante  metrics  and  descnpiions  of 
hardware  and  software  to  he  used  for  validation  testing: 

•  Se<  lion  ^  lists  spe,  ific  tests  to  whicF  the  Boeing  implemenuiiion  wits  subjected. 

•  Finally  Vviion  ”  bnellv  mentions  platform  integration  issues  which  will  he  discussed  more  fullv  m  Itie 
demoosiraiion  plan 


'I 1 J 
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2  Amrikable  doeunents 

( I J  “Na%3l  Baitlcfoise  Networking  Requirements  Report,”  Boeing  NBN  CDRL-A002,  s^nnittcd  to  Jetty 
Ferguson  CSPAWAR/ONR).  May  27. 2002. 

[2]  “Protocol  Fsaluation  Report,"  Boeing  NBN  CDRL-A004,  submitted  to  Jerry  Fe^iwtn  (SPAWAR'ONR). 
CJcioher  31,2002 

13]  ‘Tinal  Dcmonstiation  Plan,"  Biicing  NBN  CDRI.-A005.  submitted  to  Jerry  Ferguson  (SPAWARONTt).  July 
27. 2003, 

(4|  “Routing  Protocol  Source  Code  and  Documentation,"  Boeing  NBN  CDRL'A006,  submittKl  to  J«Ty 
Ferguson.  September  30,  2003. 

jS]  "OSPF  Version  2,"  Internet  F.ngineering  Task  Force  (IF.TF).  Request  for  Comments:  232*.  April  IW8. 

(bj  Warner.  C.  ef  a!.,  "Concept  of  Operations  (CONORS)  and  Architecture  for  the  Baftfcfiirce  Composite 
Network  Pro|ect."  SPAWAR  Systems  Center,  August  30,  2002 

j7]  Henderson.  T.  et  a!..  “A  Wireless  Interface  T  ype  tor  OSPF,"  Proceedings  ofltEt  MII.COM  2003 
Conference.  Boston.  MA.  October  2003 
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3  SuDinuiry  of  program  deliverables 

fable  3-1  lists  the  data  items  that  have  been  delivered  under  this  contract,  including  those  that  were  not  officially 
a  contractural  deliverable  (CDRf.). 


L  •>•** 

Item 

CDRL 

["27  May  2002 

Requirements  Report 

A002 

'  June  2002 

Protocol  Simulation  Plan 

No 

1  June  2002 

OualNet/OPNt’f  kvaluation  Report 

No 

31  Oclabcr  2002 

Protocol  Evaloatioii  Report 

A0d4 

February' 2003 

April  2003 

Draft  Integration  and  Test  Plan 

No 

Draft  Demoastration  Plan 

L-N«  ^ 

15  May  2003 

Interim  Demonstration 

No 

31  May  2003 

Interim  Demonstration  .Report  _ 

No 

17  June  2003 

Integration  and  Test  Plan 

No 

17  June  2063  * 

Internet-Draft  specification  of  Wireless  OSPF 

No 

17  June  2003 

Internet-Draft  specification  of  DSCP -based  OSPF 

No 

17  June  2003 

Internet  Draft  specification  of  DSCP-ba.sed  MOSPK 

No 

27  July  2003 

Final  Demonstration  Plan 

'  IS  Sept.  2003 

Final  Demonstration  .  . 

No 

26  Sept.  2003 

Routint  Protocol  Sonrec  Code  and  Documentation 

A006 

'  26  Sept.  2003 

(Draft)  i  inal  Technical  Report 

No 

21  November  200.3 

Final  Technical  Report 

A007 

Varkxis 

Presentation  auteriah  . . . 

AOOl 

VarloMS 

Quarterly  fininctal  reports  _ 

A04»3_ 

laHe  J- 1  Hummor}-  Composite  Routing  Jrliverahles 
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4  Overview  of  imiriemeiitatioa 

4.1  Ckmral 

The  OSPF v2  Interncl  routing  prwocol  is  ciLvently  used  in  afloat  Naval  networks  (the  Automated  Digital  htetw'ork 
System,  w  ADNS).  1  he  f^PFv2  software  developed  for  the  NBN  Composite  Routing  {xogram  contaias  the 
following  extensions  not  found  in  commercial  implementations,  as  agre^  upon  at  the  7  November  2002  program 
review 

•  DevelopmenI  of  a  wirciess  iaterface  type  for  OSPFv2.  As  detailed  in  Refereitee  2,  OSPFv2  performs; 

powly  in  a  Ivoadcast.  wireless,  single-  or  multi-hop  environment.  The  Boeing  softunre  shall  enable  more 
eflicient  operation  (bandwriefth  utilization)  over  wireless  networks  witlwut  significantly  r^hicing  the 
tuccesiful  nwling  of  packets.  .  , 

•  QoaUty-trf-Sendce-based  rooting  through  UbC'P-based  liak  netries.  The  Conqjosite  Networking 
progrMt  managed  by  Dr.  Cliftord  Warner  of  the  SPAWAR  Systems  Center  is  developing  a  Next- 
Generation  C2P  that  enables  range  extension  over  the  Navy  ADNS  by  using  dif&rmtiated  services 
codepoints  (DSCP)  to  mark  traffic  In  the  current  OSPFv2  networks,  special  handling  of  DSCP-marked 
packets  can  only  he  accomplished  through  static  configuration  of  router  schedulers  By  enabling  DSCP- 
bas^  link  metnes  for  OSPI  v2,  DSCP-spccific  routes  through  the  network  can  be  constructed  by  the 
routing  protocol 

Die  unplementaiion  is  based  on  modifications  to  the  OSPrv2  reference  implementation  maintained  by  the 
OSPI  v2  autlior.  John  Moy.'  The  software,  called  ospf  d,  is  an  open-source  software  implementation  covered 
under  the  GNU  General  Public  I  icen.se  (CiPL).  It  supports  both  unicast  and  multicast  (MOSPF)  protocol  operation 
The  software  is  w-ritten  in  C*  -  and  can  operate  as  a  user-space  process  using  standardized  kernel  APIs 

The  hardware  platforms  used  for  the  demonstrations  were  Intel-based  rack  mount  systems,  ATX-ehassis 
computers,  and  laptops,  and  AR.M  -based  PD\s.  all  running  Linux  kernels  in  the  2.4  scries  The  computers  used 
tihemct,  senat  (Rfi4?2),  and  wireless  LAN  (802. 1  lb)  inierfaces.  Routers  had  an  SNMP  agent  visible  from  standard 
SNMP  monitoring  fools 

4.3  Reqairements 

!  be  L  llc'wing  subscction.s  summan/c  the  program  requirementsi  We  have  met  all  program  requirements 
ligarding  implemcntaiion.  intcgraiioii.  and  testing,  except  ihc'se  otjviaied  by  the  selection  of  OSPFv2  extensions  as 
the  riHiimg  protocol  to  be  developed  under  this  contract. 

4.2.1  Implementation  requirements 

i  he  fc  llowing  implementation  ic^uirtments  arc  copied  from  ( 1 ): 
l-K : .  I  he  mipleiiieiiUlion  shall  be  based  on  Linux  2.4  kernel. 

1-R2  Ihc  implementation  shall  be  written  to  operate  as  a  user  space  process,  using  standardized  kernel 
APIk  as  much  as  possible 

l-R.l  The  implementation  shall  be  wniten  in  the  ANSI  standard  C  or  f'»  •  programming  language, 
compilable  by  the  Gnu  C  compiler  (gcc)  version  2.^6  or  greater, 

I-R4  The  implcntentation  shall  be  compatible  with  Ethernet  ( lOBascT  and  100BaseT)  intcr&ccs 
l-Rf*  Ibe  implementation  shall  be  compatible  with  a  serial  interface  (RS422). 

I-Rs  Ihc  implcmenlaiion  shall  include  an  objrcl  that  can  be  managed  according  to  the  Siijqtfc  Network 
Management  Protocol  versi<*n  2  (SNMPv?)  Network  Management  Framework 

l-R"  The  implementation  shall  log  errors  or  unusual  events  to  a  system  log  file 

1-R»  Ihe  c  miractor  shall  prepare  a  "User's  Guide”  for  the  implementation,  including  Imiw  to  configure 
and  rxrtuie  the  imp  cmentatsm  via  a  command  line  interface  and  text  configuration  file,  as  well  as 
tonfiguration  for  system  smrt  up 

hup  *WWHSpfof}> 
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I-R9  The  source  code  shall  be  delivered  on  CD-ROM  media. 

I-R 10.  The  source  code  shall  be  coded  and  documented  according  to  contractor’s  best  current  practices. 

4.2.2  System  integration  and  testing  requirements 
The  follnunng  system  integration  and  testing  requiremenui  are  copied  from  [1]; 

S-RI.  The  contractor  shall  instafi  the  implementation  into  a  standard  1  or  2  rack-unit  server  including 
10/ 100BaseT  and  serial  PCI  interface  cards. 

S-R2.  The  contractor  shall  install  the  implementation  into  standard  mid-tower,  ATX  based  chassis  should  an 
insunicient  number  of  rack-mountable  servers  be  available  for  demonstration. 

S-R3.  The  contractor  shall  test  the  correct  operation  of  the  serial  and  Ethernet  interfaces 

S-R4  The  implementation  shall  interoperate  with  routers  based  on  OSPFv2  routing  protocol  via  route 
summarization.  (Note:  This  requirement  has  been  overcome  by  the  decision  to  develop  OSPFv2 
estensious  rather  thaa  a  separate  protocol.  Therefore,  there  it  no  requirement  to  interwork  via  route 
summarization;  iaterworking  oecurs  through  normal  OSPFv2  awchanitms.) 

S-R5.  The  implementation  shall  interwork  with  available  Linux  trafTic  control  software  that  supports  prioritized 
handling  of  traflic  ba.sed  on  quality -of-service  markings  in  the  packet  header. 

S-Rft  The  impirmenfaiion  shall  be  able  to  simultaneously  coexist  with  OSPFv2  touting  processes  operating  on 
other  mtcrfaces.  (Note;  This  requirement  has  been  overcome  by  the  decision  to  develop  OSPFv2 
csteusions  rather  than  a  leparate  protocol.  Therefore,  there  it  no  reqairement  ta  support  multiple 
routing  processes-  a  single  OSPFv2  routing  process  shall  support  all  interfares.) 

fv-R?  The  contractor  shall  develop  a  test-suite  to  test  the  cotiect  operation  of  the  implementation.  Thi.s  test 
suite  shall  include  link  impairments  designed  to  test  the  operation  of  the  routing  protocol. 

S-R8  The  contractor  shall  test  the  ability  for  a  standard  SNMPv2-bascd  element  manager  to  manage  the 
implementation 

S-R*)  The  contractor  shall  define  and  conduct  tests  that  ensure  that  the  implementation  is  prepared  for  system- 
level  experiments  and  dcmonstrationj 

4.. '  Software  archileeturr 

Ru.nning  the  user-space  routing  daemon,  espf  d.  tunt.s  a  Linux  machine  info  an  OSPF  router  that  communicates 
with  the  kernel  to  manipulate  routing  tables  and  send  and  receive  packets  with  otlwr  OSl’k  routers.  The 
impicmcnution  requires  changes  In  allow  for  the  new  wireles.s  tnlerfacc  type  and  for  performing  QtOS-based 
louiiiig  Figure  4-1  depicts  the  flow  of  data  through  the  application.  Numbers  indicate  points  where  the  code  has 
been  nxxiified  for  the  NHN  Composite  Routing  program  to  support  DSCP-based  trtctrics 

I  he  Linux  daemon  interacts  with  the  operating  system  kernel  in  several  ways  The  code  for  these  sundunl  Linux 
system  calls  has  been  modularized  into  a  separate  library,  to  ease  porwhihty  to  other  platforms  For  sending  md 
rcccuing  OSPf  packets,  the  r.cntim.'iq  ( ) .  SPtdro  ( ) .  select  ( ) ,  reevf  .-'om  f) .  and  recvnisg  ( )  calls  are 
used  with  raw  IP  siKkels.  "Nctlink”  sockets  handle  the  addmg  and  deleting  of  routes  in  the  kernel  routing  Ubic  and 
receiving  interface  information  I  he  .sigiidl  ( !,  sigadct.set  (l.andset  itimer  ()  kernel  signaling  functions 
manage  timing  events  and  shutdown  Logging  is  performed  with  the  syslog  ( )  facility.  The  routing  daemon  is 
configured  with  a  plaintext  configuration  file  /  et  c  /ospf  d .  cont .  this  file  is  parsed  on  startup  using  a  I C:i.  script 

4.. T.1  C  hanges  to  support  I)S<:P-f  nahled  ronting 

Here  is  a  brief  overMfw  of  the  modificattons  highlighted  m  Figure  *■  I  We  modified  the  configuration  script  (1) 
so  that,  within  the  configuration  file.  l)S(  P  type  metnes  can  be  specified  for  each  interface  The  representation  of 
iIk'  ospf  interface  has  an  aicsociaied  metric,  which  has  been  enlarged  (2l  to  an  array  of  metrics,  one  for  each 
possnie  DSL  P  ciKlcpomt  W  hen  I  SAs  arc  onginan-d  by  an  interface  t the  appropriate  DSCP  link  nietncs  arc 
included  when  available  Fdch  link  (between  two  routers)  is  represented  by  a  link  object  it.  the  OSPF  link-state 
database  we  miKiified  this  data  structure  so  that  tlw  cost  of  a  link  is  an  array  that  can  store  any  tyj^  of  cost  indexed 
b>  nS(  P  codepotni  (4)  When  incoming  1  SAs  are  parsed  (5).  the  DSCP  metnes  are  stored  in  the  link  object  The 
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rmiiing  calculation  (6)  b  repeated  for  every  DSCP  type  that  has  been  encoup'  .a«l  in  (he  IWt-sttte  datiime.  Routes 
are  stored  in  a  rwjting  table  (7)  has«l  on  their  MCP  t)TJe.  When  calculating  a  route  to  a  destmaticMi  fw  a  spaific 
KCP  codepoiM.  and  an  end-to-end  path  using  «ily  DSCP-enabled  metrics  for  that  codepoint  does  not  exist,  a  path 
will  be  coiBtnieted.  if  possible,  bas^  <m  all  available  type  0  (normal)  links  and  metrics.  FmaBy.  uaica.'U  rwnes 
added  to  «  deleted  from  the  kernel  (8)  now  carry  a  DSCP  codepoint,  and  the  kernel  ch^ls  ftw  a  route  ha^d  mi  tte 
W*CP  codepoint,  selecting  die  type  0  route  if  no  DSCP  route  is  avaiMile 

Multicast  rmitir.g  in  the  Linut  ketnel  is  implemented  via  a  muliica.st  cache  which  preseiMty  does  nen  suf^soit 
DSCP  values  m  the  same  way  as  the  unicast  routing.  However,  we  can  still  acconsplish  multica.st  routing  based  on 
ttiCP  cfstepoints  without  kernel  modincaiion,  if  we  assume  that  all  traffic  to  a  particular  nwlticast  group  carries 
the  same  DSCP  codepoint.  This  is  acconqilishcd  without  kernel  modification  by  bavit^  the  MOSPf  process 
examine  the  dsu  packet  for  a  DSCP  codepoint  and  by  then  using  the  DSCP  routir^  infonn»ion.  if  mailable.  Ilic 
resultant  multicast  route  installed  in  the  kernel  will  be  used  by  every  multicast  packet  to  that  regardless  of  its 

DSCP  ctdcpomi 


f  igun-  4  1  Software  arihiterture  for  OSPFv2  daemon  with  f)SCP  modifkatiems 

I  Ih-  I  iiiu»  kciiK’l  can  Kiake  routing  decision.s  based  on  the  second  octet  of  (he  IP  header.  In  standard  Linux 
kerne  ls  this  field  is  treairal  as  the  TDS  value  (defined  by  Rl  (  1 149).  wh.ch  means  that  only  three  bits  are  used, 
allow  ing  only  eight  possible  value.s  to  differemiate  routes  We  use  a  patch  for  the  kernel  so  this  field  is  ttcated  as  a 
DS(  I*  ctdcpoml  (defined  by  HI  C  241  f  ).  allowing  full  six  biH  or  M  possible  DSCP  values.  The  pnieh  works  by 
rcdcfinini*  the  mask  that  is  applied  to  the  second  iK'let  when  the  value  is  extracted  ftom  the  IP  header. 

4..1,2  Implementalloii  ehanKM  (•  support  wireless  inlrrfKf  type 

We  miHlified  the  configuration  senpt  ( I )  *o  that  within  the  configuration  file,  wireless  (ttPF  inftwtacc parameters 
lould  he  specified,  such  as  the  wmfcss  hello  intersal  and  fiixidmg  interval  II.SF  intervall.  In  (2),  anew  interface 
was  adikJ  for  wiicicss  OSPI  I  he  iiiieitacc  is  a  hybiid  vcisum  of  the  broadcast  «id  point-lo-mullipoiiw  interfaces. 

1  he  need  lor  adjacencies  ( IJ  is  eliminated  because  we  arc-  using  unreliable  flooding,  so  database  synehromKrtioii  is 
r  ..  I..tig<  *  performed  Additional  timers  (4)  have  been  added  for  the  wireless  hello  mic-rval  I  SI  interval,  and 
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vanous  as^octated  expiration  times  are  monitored.  The  origination  of  new  LSAs  (5)  has  been  changed  to  occur  on  a 
periodic  basis  corresponding  to  the  LSF  interval  as  opposed  to  a  reactive  approach  to  link  failure.  I  be  sending  and 
flooding  (6)  of  LSAs  has  been  modified  to  enable  the  sending  of  wireless  hellos  and  LSFs.  In  addition,  the 
Multipoint  Relay  fMPRi  algorithm  is  used  to  optimize  the  flooding  of  packets.  Code  to  receive  (7)  the  new  packet 
types  has  been  added.  The  use  of  database  description,  LSUs.  LSAcks,  and  LSRs  (8)  has  been  eliminated  on  the 
wireless  interface.  Hello  packets  (9)  are  replaced  with  the  wireless  helb  packet  that  contains  a  list  of  MPRs. 


f'tgur<’  4-  2.  Software  an  htfcturp  for  OSPFv2  daemon  with  wireless  modifica:ion.s 


4.3.3  F.vent  toggiag 

In  addiikin  to  the  esisting  event  logging  that  takes  place  when  the  daemon  is  run,  the  following  items  are  now 
recorded  to  the  log  file  (  var  lrg  ospfd  log) 

•  I  og  message  that  was  "Receistd  Pkt  type  is  iu*w  “Received  Wueles.s  Hello  . 

•  Log  mcs.sage  that  was  "Received  Pkt  type  7"  is  now  “Receivcvl  Link  State  I  lin'd". 

•  When  there  is  a  link  failure  on  the  WANK  Intoifacc’s  serial  line 

•  W  hen  there  is  an  IW  SPY  status  change  due  to  a  bad  signal-to  noise  ratio  (optional  feature) 

•  When  neighbors  are  added  to  or  deleted  from  the  IWSPV  monitonng  list  (optional  tea’ure). 

•  If  a  DSCP  M(  )SPF  calculation  fails,  and  uses  rhe  1>SC  P  0  muliicasi  tree  inste.id 

•  If  wc  sub.sinuic  DSC  r  0  metric  foi  legO'  >  router 

•  When  a  new  network  l.SA  is  received  <»n  a  wireless  interface  that  obsolctcs  an  enisling  one. 

•  W  hen  a  new  del.vuli  route  is  aildcd  or  deleted  for  a  wireless  stub  area 

•  When  'he  MDSPI  cache  is  cleared,  to  bcttiT  umk-rstand  when  multicast  cache  entries  are  absent 

•  WtK-ii  4  ttmliii  asi  routing  calculation  is  rc«tuesied  for  ait  invalid  niuliicast  wiuicc 
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•  After  cacli  dyksira  calculatim,  the  number  of  dijkstra  calculation*  Wat  have  occurred  mbcc  dw  d^moii 
WM  Man«l.  rrh»  statistic  is  incremented  once  for  each  recalculation,  not  once  per  DSCP  dijkstra  run.) 

An  t^kni  may  be  wm«l  on  at  c«i^ile-tiinc  to  generate  a  second  log  file  (/var/log.o^fd  log2).  This  additional 
tog  file  is  helpful  for  keeping  uack  of  changes  to  the  wucless  network.  The  following  items  are  togged  wd^n  a 
*irclc«  interface  type  is  defirwd: 

•  The  Hm  of  one-hop  neigitoors.  and  the  corresponding  two-hop  neigltows  dim  can  be  reached  dirough 
diem 

•  The  lia  of  neighbors  this  node  has  selected  as  MPRs  (MPR  list). 

•  The  list  of  neighbors  selecting  this  node  a*  MPR  (MPR  selector  lisii. 

•  Whr-M  an  LSI  is  being  forwarded. 


4.4  PerfarManee  nKtricvlest  crticria 

T  he  OSPFvl  software  was  evaluated  on  the  basis  of  iclcrc^erabiljty,  eorjeclncss,  and  Ecrformancc.  With  respect 
to  intcroperabiiiiy.  the  Linus-based  OSPFv2  routers  were  connected  to  a  network  containing  ig>  to  thieeCisco 
r«ncr*  ntiming  OSPFv2.  aiKf  tests  were  performed  dcmonsiraiing  the  modified  ()SPFv2  software  successfully 
intenipcrating  with  the  C isco  software  Ihe  correctness  of  the  implementation  was  tested  by  configuring  the  testbed 
it>  cscrcise  certain  part*  of  the  code  and  by  observing  the  resulting  routing  tables  and  packet  traxs  from 
espenmems  The  software  was  also  tested  ft-r  performance  by  specifically  contrasting  the  toleration,  of  OSPFv2 
legacy  software  with  the  operation  of  die  Boeing  fstension!..  using  s».lccied  network  configurations  Tiaffic 
generation  and  post  processing  of  traffic  traces  was  used  to  establish  performance  metrics,  including  the  following 
key  metrics 

I)  CjSPF  v2  overhead  ettnsumed  (meat ured  at  IP  layer): 

•it  Pa'kis  delivery  ratiti  for  user  data  traffic,  and 
nil  Convergence  time  of  muting  uhles 

4.5  ft^wpmeat/sortW'are  to  be  osciJ 

In  addition  to  the  t.mus  based  muiers.  ivur  testing  used  the  equipment  and  software  listed  below 

4.5.1  Ronlers 

CIseo  3AW  series:  Ihe  Cisco  ,1600  seres  router  is  a  modular,  multiservice  access  platform  fiir  medium  and 
laige  sired  offices  and  smaller  Iniemet  Service  Providers  Specifically,  our  laboratory  testing  used  C  isco  iMfK 
equipped  wiih  IfiS  version  12  2  4 

C  Hco  AI5II  aeries:  Our  dcmonstraiMin  used  (  isco  Mobile  Access  Routers  (MARI,  a  special  Pf  -lOa  form  factor 
router  capable  of  RIPv2  and  OSPI  v2  routing 

Dl.fiR  rMting  software:  We  have  rtvsliried  the  OI.SR  routing  si'ftware  dislnhuled  by  loe  Macker  iNRl.J  for 
operation  with  assoeiatrd  sfu^  subnets  We  u.sed  this  softw  are  to  comp.m-  its  frrformamre  against  that  of  ,wir 
inidi^cJOSPf  v2  iniplenH-nlahon 

4.5.2  Inteifaee  cards 

,».l.  si  routers  were  equipped  with  PC  l-bas,  d  l(»  KKl  I  thcmel  cards,  tvpically  Intel  I  therl  spress  Pro  In  addition 
we  icsicd  with  U(t2  1 1  b  cards  wh  as  C  iriiHKo  f  mid  cards  and  ai  ccss  points,  and  we  used  Uw  Wanic  52.1  serial  card 
to  ensure  serial  iniertace  eompaiibilily 

4.5..5  Data  ehanncl  timulaiors 

Vs  I  used  the  toilowing  channel  simulators  and  emulators 

Mobikimi:  M»>hil mu  is  a  Uh>I  for  emulating  mobile  ad  hoc  network  environniciit  with  a  fixed  iwlwork  of  Linux 
m.i.  him  .  f  kernel  2  4  ami  ahine)  in  a  I  ab  setiiny  It  can  support  virtually  any  mobility  sccnano  fsiwh  as  ns2 
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scenarios)  without  actually  moving  the  nodes  physically.  It  is  good  for  MAN!-,  I  (mobile  ad-hoc  network)  research 
that  requires  testing  a  real  implementation  or  application  with  different  mobility  patterns. 

Adtech  SX/13:  I  he  SX  Data  l  ink  Simulator  creates  the  same  delay  and  error  characteristics  caused  by  long 
distance  terrestrial  and  satellite  data  links.  Witli  dual-channel,  full-duplex  operation,  the  simulator  provides  bi 
directional  testing  with  programmable  delays,  random  bit  errors  and  burst  errors.  Multiple  delay  and  eaor  events  can 
be  programmed  to  simul.ite  a  wide  variety  of  chronic  and  periodic  conditions  or  events  such  a.s  peak  traffic  times 
and  equipiTk'nt  overloads  In  our  testing,  the  Adtech  SX'  I  ?  will  be  used  to  as  channel  simulators  for  the  serial 
interfaces 

4.5.4  i  raffle  generation  and  measurement  ■  ' 

C  harlot:  Chariot  is  a  commercial  tool  that  emulates  network  users  by  sending  tniffic  over  the  network.  It 
emulates  nulliplc  data  types  and  rates  using  diffcicnt  protocols,  and  measures  performance  between  pairs  of 
networked  computers.  .Ml  computers  included  in  tests  have  NcflQ  Performance  software  installed  C  hanot  uses 
real  data  to  emulate  and  test  different  applications  through  the  network,  and  to  monitor  from  its  con.solc  all  traffic 
between  endpoints  We  used  Chariot  at  our  interim  demonstration  in  May.  2003. 

MfILN/DRKC:  1  he  Multi-Generator  (MGliN)  is  open  .source  software  by  the  Naval  Research  laboratory 
t  NRL).  MfiTN  provides  the  ability  to  perform  IP  network  perfonrance  tests  and  measurements  using  UDP1P 
traffic  ( 1  (  P  IS  cu-menily  being  developed)  1  he  toolset  generates  real-time  traffic  patterns  so  that  the  network  can  be 
loaded  in  a  vanety  of  w.iys  The  generated  traffic  can  also  be  received  and  logged  for  analyses.  Script  files  arc  used 
to  drive  the  generated  loading  pat*ems  over  the  course  of  time.  These  script  files  can  be  used  to  emulate  the  traffic 
patterns  of  unicast  and  or  multicast  UDP  IP  applications  The  receive  portion  of  thi.s  fool  set  can  be  scripted  to 
dyiiaiiiically  join  and  leave  IP  multicast  gioups.  MGEN  log  data  can  be  used  to  calculate  (lerforniance  statistics  on 
throughput,  packet  loss  rates,  communieation  delay,  and  more. 

I  cpdump:  I cpslump  is  a  packet-capturing  uiiiity  for  Unix-ba.sed  machines.  It  allows  a  user  to  view  the  live 
network  traffic  passing  on  the  wire  by'through  the  user's  host.  It  displays  output  on  a  console  or  can  wntc  binary 
files  into  a  .standard  format  fo-  post-prcKcssing  , 

Ethereal:  Ethereal  is  a  free  network  protocol  analyzer  frir  Unix  and  Windows,  which  pmvides  a  nice  graphical 
user  interlace  for  Icptiump  Ethereal  has  several  powerful  features,  including  a  rich  display  filter  language  and  the 
.ibility  to  vi?w  the  rect'nstructed  slrcam  of  a  'I  CP  .session  We  plan  to  write  extensions  to  Ethereal  to  support  the 
OSPEv2  protocol  evlcnsion.s  we  are  developing. 

(  usiom  logging  scripts:  Part  of  our  testing  required  logging  of  information  regarding  routing  table  updates  and 
packet  de''Ii\crv  'A  c  developed  customized  senpts  on  an  as-needed  basis  to  support  our  data  collection  and  amilysis. 

4.5.5  Network  management  software 

scoffs ;  The  opeii-s.icrce  s rot  t  y  Kx>l  provide.s  a  GUI-based  capability  to  monitor  SNMP  agcnt.s  on  rc.sident 

dev  ICCe 

Net-.S.N.MP  agent:  c  in.stalled  the  open  s*)urcc  net  SNMP  agent  on  the  routers. 

•f.5.t>  k,K>S  software 

f  he’  I  inux  adv.'.nced  rou’ing  and  traffic  control  (I  .NRTC )  framework  provides  a  number  of  built-in  fwls  to 
manage  traffic  for  (koS  management.  In  our  tests  and  denionstraiions,  we  combined  tJic  DSCP-bascd  routing 
e\te‘n>ii>ns  w  ith  DS(  P-cnahled  pnoniy  queue  scheduling 

4.5.7  Software  verification 

Insure-^:  In'ure  •  ■  is  a  commer  ialiv -available  nin-timc  C  code  analyzer  that  is  designed  to  examine  code  for 
many  classes  of  implementation  errors  noi  commonly  found  by  compilers,  including  memory  access  violations, 
memory  leaks,  pc  inter  errors,  data  type  errors,  and  library  errors 
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5  Vtreless  OSPFv2  testing 

(Jur  two  main  objccines  in  wirclcs'i  f  )SPFv2  testing  were  to  (i)  %'alidaie  that  the  basic  optaation  of  the  pmiocol, 
within  a  single  MANET  .'Wibnet,  was  similar  to  that  observed  in  simulation,  and  (ii)  test  the  implementation  for 
correctness  in  a  variety  of  network  configuraiion.s 

5.1  OSPF»2  router  configuration 


Figure  5- 1  illustrates  a  representative  <lSPFv2  configuration  file.  Unless  tilherwise  .specified,  die  values  slmwn  in 
Fu'iiri*  “t-l  were  used  in  ihe  tests  described  bekm^ 


r:>u*er.d  10.0.0.2 
n.o.-spf 

ci.scp  rout  inq 
loq  .  iirvel  0 

a 

cl  -•  ea  0 . 0 . 0 . 0 
ai;r.errarf  10. 0.0. 2  1 
WO!^pf 

#St,ub'di  rr*less 
<  i.s  p  f  I  f  Au  t  hTypf!  ? 

.•rdlkcy  1  shareid.secreti 

'ispi  I  f  i*.»l  ir  liit  erva  1  2 
ur.pf  I  f  Lsf  In:  er'/al  2 
ppr  t  i.Tf  A 

nntif  I  fFi-  rV.licartln'.c'.'val  6 
-  qirpv.uit  yl nt  et  v<il  i  0 

:n:erfa:7e  ethi  1 

y/fiun'  f 


/*  Variable 

■*  Enables  MOSPr 

/*  Enable.s  DECf- based  routing 

(•  *  Extent  of  log  messages  found  in 

•  /var / log/ospf d . log 

•  classify  the  follow  interfaces  in  area  0 
/•  assign  interface  and  metric 

/*  set  the  interface  type  as  wospf 
/*  optimize  interface  by  setting  as  a  stub 

/*  set  up  the  use  of  authentication 

•  with  mdSsur 

/  *  set  the  hello  interval  to  2  seconds 

■"  set  the  LRF  -..nterval  to  2  seconds 

'•  set  the  hPP  Selector  expiration  interval 

•  sot  the  neighbor  dead  interval 

/■  *  set  the  igmp  query  interval  for  faster 

•  muiticasi-  routing 

/ *  assign  broadcast  interface  and  metric 
IM  fault  muter  configuration  far  wireless  OSPF 


*! 


•/ 
•  / 


’/ 
*  / 
•  / 

*  I 

*  ■ 
*  / 


5.2  Bade  MANET  testing 

I  his  test  IS  a  fuiidanicnlal  test  of  hnw  tlic  wireless  OSPi  v2  interface  performs  in  comparison  toan  OLSR 
implemeniaiion  and  a  legac  y  Point  to-Multipomt  (PTMP)  OSPF  implementation  In  addition,  wc  wrote  scripts  tliat 
allowed  us  to  exactly  replicate  the  wireless  emulation  environment  in  simulation,  and  compared  our  wireless 
OSPI  V?  implememalion  with  our  simulaiion  models  that  were  used  in  (7) 

I  his  testing  consisted  of  N  routcis  with  Fthemet  interfaces  connected  to  the  mobile  nelwrork  emulator  as  shown  in 

Figure  52-1’ 


Linux  rouirr  I 


Linux  router  2 


•  •  • 


V- 

.Mobile 

■etwork 

emulator 


Linux  router  N 


figure  5.2  /  Busu  MASET  Routing  TeslheJ 

Test  procedures:  The  synthetic  network  emulator  ( SNFl  was  configured  w’idi  three  scripts  of  increasing 
inohilii  V  I  he  mobility  are.t  was  .5tl0m  x  SOOm  and  the  simulatwn  rati  for  30  minutes.  The  radio  range  was  i4(lni  m 
the  S  node  case  and  20Um  in  the  16  node  cast  T  he  max  speed  and  max  pause  time  fortlw  liigh.  medium,  and  low 
scenarios  were  lOOmsand  Is.  2.Ams  and  4s,  and  hV.Sm's  and  I6s  respectively.  The  Unux  routers  were  first 
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;onfigurcd  m  poini-to-niuliipoirit  mode,  and  baseline  jests  were  nin.  Next,  OLSR  was  installed  on  all  routers  and 
idciuical  tests  were  conducted.  Finally,  the  Linux  routers  were  reconfigured  in  wireless  OSPF  interface  ntode  and 
the  tests  were  repeated  again.  The  routing  daemons  were  started  asynchronously  over  an  initial  30  minute  startup 
period  in  order  to  avoid  hursts  of  overhead  when  timers  fire  periodically.  The  hello,  1,SF,  and  TC  intervals  were 
each  set  to  2  seconds  unless  otherwise  specified  below,  and  the  dead  intervals  were  set  to  three  or  four  times  the 
hello  interval .  Each  node  sent  a  1 6  byte  UD?  packet  to  every  other  node  on  5  second  intervals  so  statistics  could  be 
calculated  on  the  packet  delivery  ratio. 

Measurements  and  data  processing;  We  ran  tepdump  on  each  router  and  saved  the  results  to  a  log  file  1  he 
iogfilc  contained  the  LiiP  traffic  sent  and  received  m  addition  to  the  overhead  generated  by  OSPf  .  W'e  then  post- 
processed  the  data  to  extract  utilization  and  delivery  ratio  statistics.  Network  routing  tables  were  periodically 
dumped  and  post-processed,  and  compared  against  the  nctwiM-k  emulation  scciiaiio. 

f  2.]  Implementation  results 

1  he  results  below  (Figures  S  2-2  through  5.2-5)  give  the  overhead  and  delivery  ratio  for  8  nodes  and  then  I  h 
mxles.^  In  the  8  node  ca.se,  standard  OSPF  PTMP  is  in  a  range  where  it  functions  as  good  or  better  than  OLSR  and 
\\  OSI  r.  The  8  node  sccnariu  does  not  portray  the  adverse  affects  of  large  amounts  of  overhead  Flowever.  when 
the  8  node  scenano  is  taken  in  context  with  the  16  node  scenario  it  is  evident  that  PTMP  OSPF  cannot  be  scaled 
much  over  16  nodes  In  addition,  it  ts  seen  that  the  overhe.ad  produced  by  PTMP  is  significantly  impacted  by  the 
degree  of  mobility  because  routing  is  triggered  by  link  changes.  The  ovcrtiead  produced  bv  OLSR  and  WOSPF  is 
not  significantly  impacted  by  mobility  because  routing  is  triggered  by  periodic  timers.  Flowever.  the  overhead  is 
directly  affected  by  tlic  tiiiici  intervals  For  less  mobile  scenarios,  timer  intervals  can  be  significantly  extended 
above  the  2  second  inierva!  tested  here  without  significantly  compromising  routing  protocol  performance 

01  -S  R  yields  good  i c.sult,>  in  ilic  8  and  1 6  node  scenarios.  1  he  overhead  is  at  a  minimal  level  while  the  delivery 
ratio  IS  comparable  lo  OSPF  PIMP.  This  result  is  to  be  expected  because  OL.SR  is  optimized  for  the  basic  M.NNFT 
network.  It  is  seen  that  WOSPF  scales  much  better  with  respect  to  overhead  than  PTMP.  T  his  scaling  property  is 
the  mam  advantage  in  using  a  wir.eless  interface. 

<  )SPf  generates  approximatclv  2  or  3  limes  more  overhead  than  OLSR.  The  increase  in  overhead  is  because 
OSPF  IS  a  full  link  .state  protocol,  with  each  node  originating  an  LSA.  In  contrast,  OLSR  only  generates  T C 
mess,3ges  from  those  routers  who  are  MPRs  This  cawscs  WOSPF  to  have  a  slightly  higher  delivery  ratio,  but  it 
gcncraic.s  more  overhead  in  well  connected  netwc>rks  W(.)SPf  does  not  adopt  the  OI.SR  TC  mcss,agc  mechanism 
because  II  reprcNcnis  more  of  a  departure  from  how  OSI’P  implements  its  databases,  thereby  affecting  compatibility 
with  legacy  OSPf  routers 
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Fv^’ure  *  2-4  Compiinniri  of  the  overhead  generated  hv  implemented protoe  of ^  in  a  16  tmle  network. 
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Cttmpanson  of  thf  eJeH\  <‘n  nuio  ohlained  fiom  implemented  prottKoh  in  a  node  network. 


5.2.2  Simuiatioo  comparison  results 

V^  e  ncs(  ported  our  wreless  network  emulation  senpts  to  thcOualNet  simulator,  so  that  we  could  reproduce  the 
exact  network  behavior  in  simulation  This  exercise  allowed  us  to  validate  our  simulation  models  Figures  5  2-6 
through  6  .2-1 1  show  the  close  match  between  simulation  and  implementation  results  shown  in  the  previous  graph 
l'hi>  close  match  gives  us  confidence  thtit  our  simulation  can  be  faithfully  scaled  upwards  in  the  number  of  ntxfes 

.Although  the  companson  in  results  is  very  close,  in  all  three  protocols,  the  delivery  ratio  is,  on  average,  slightly 
lower  for  tlic  iniplcmcntaiion  In  a<lditKin.  for  the  eight  node  case,  the  overhead  is  lower  for  implementation  when  at 
the  highest  mobility  I  his  is  probably  due  lo  slight  differences  in  the  OualNcfand  implemcntulion  mobility  scripts. 

f  be  result-  found  in  simulation  for  the-  P I MP  OSPF  compare  very-  closely  with  those  found  m  simulation.  I  here 
IS  a  mirnir  discrcpam-y  in  delivery  ratio,  but  this  could  be  due  to  minor  variations  in  the  mobility  scenarios 

<  >LSR  alv)  yields  similar  results  in  simulatum  and  impiemcntatum  I  here  is  some  diflcrcncc  ui  the  overhead  that 
IS  ..-aiisi-d  hv  dissimilar  t  )l ..SR  versions  The  implemeniaiinn  is  version  1  while  the  QualNel  protocol  is  version  7. 

I  he  packet  fields  were  mixiified.  making  version  7  more  overhead  intensive. 

(  he  comp.irison  of  iinplcmentaiion  and  VuaINct  is  very  similar  ftu  WCiSPF. 
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/  V  (  omparnon  of  the  deli\er,  ratio  ohrumed  hv  the  mplementatton  and  QuatSet  ma  16  node  network 

I  font  th<-  ri-MiliN  shi'wn  in  F  igiircs  5  2-^  to  5  2-9,  ii  is  obscrvcil  mobiluy  has  little  impact  on  the  overhead 
produced  hy  \Vt )SPF .  but  mohiLfv  highly  effects  the  overhead  produced  by  PTMP  with  2  second  timers.  1  he 
fCMilis  shown  in  higures  S  2-10  to  5  2-1 1  show  the  sin  ilar  tests  t>ut  with  slower  mobility  and  10  second  timers  I  ho 
mobility  I  iassilied  as  "I  ( >W'  in  the  previous  figures  was  considered  as  "lIKiH"  mobility  in  the  next  two  figures, 
and  "I  ( »W  anti  'Mi  l  >11  M"  mohiliiy  rates  were  rescaled  accordingly 

in  itK  v  results  we  again  observe  that  WOSF'I  is  more  resistant  to  overhead  swamping  due  to  mobility  than 
P 1  Ml’  W  hen  the  network  is  highly  mobile  iapproximately  a  70^.  delivery  ratio),  the  overhead  of  OSPF  PI  MP  is  4 
to  ^  times  gre.tier  th.an  WC»SPI  Another  tnierestmg  observation  is  that  there  is  more  overhead  with  the  10  second 
timer  .if  -  f  IK  iH"  mobility  (same  as  "I  ( )W"  mobility  with  2  second  timer)  than  the  2  second  timer  at  "l.OW" 
mobility  again.  iFa’sc  mobiiiiv  rates  are  the  same  The  results  indicate  that  extra  hello  tratfic  in  P  fMP  can  iK’Ip 
del  jv  the  sw.imping  of  a  network  because  links  are  changing  faster  than  routers  can  synchronize. 
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t  igur>-  '  !ff  ( ttmparium  of  the  overhead generaicd  hy  the  implementation  and  QualS’et  in  u  16  node  network  with 

timerv  set  on  10  second  intersals 
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/  lyuft  5  2  11  Companson  of  the  defnety  ratio  obtained  bv  the  implementation  and  {luidNet  ma  16  node  ihtwork 

with  time's  set  on  10  set  and  intenvis 


I  hi*  amount  <»f  <tvcrtwad  ^'cneraicd  by  PTMP  in  K  and  16  node  networks  is  nianaiteabk  in  802.1 1  networkit 
runniiti!  at  1 1  Mbps  I  lowever.  the  above  results  show  tlie  bend  that  P  I  MP  does  not  scale  well  with  respect  to  the 

number  of  r«>uter.s  m  a  iwtwork  Thi  followinp  results  (simulation  only)  show  how  PIMP  scales  with  respect  to 
Wt  iSPI  fiif  between  8  and  36  node*. 


•%ll  pics  lous  results  were  obtained  for  comparison  vahdaimji!  simulation  with  in^lemcntation.  so  fcthemet  was 
used  at  the  link  layer  (the  wireless  network  emulator  is  actually  an  Ithi-met  bndpe  which  selectively  enables  and 
dis.iblcs  rcc,*ptiiin  ofMAf  addresses,  but  the  unJerlying  (SM.A'f  D  MAI"  properties  w  in  effect).  Use  of  an 
I  the  met  link  layer  implies  that  the  coIIisioils  were  verv  minimal  and  the  transmission  tinic  was  low  In  the 
lollowinj'  results  the  MAf  layer  used  was  802  I  lb  with  R  fS  f  fS  enabled  bach  router  has  a  radio  range  of  250 
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meters  1  he  mobility  of  each  node  was  set  to  move  to  s  random  location  between  0  and  lOnvs  and  then  pause  for 
40s  before  moving  again. 


1  he  data  below  comes  in  two  forms  for  PTMP  and  WOSPF.  One  line  (solid  shapes)  shows  the  results  when  the 
mnie  density  is  scaled.  1  his  means  the  simulation  area  remains  the  same  and  tlic  number  of  nodes  increases,  1  he 
second  line  (hollow  .shapes)  shows  a  static  node  density.  The  simulation  is  scaled  with  respect  to  the  number  of 


nodes  according  d  — 


|500-\V 


,  where  N  number  of  nodes  All  results  for  scaled  node  density  were  run  in  a 


.5(X>m  by  500m  area.  1  he  static  node  density  scenarios  were  run  with  a  node  density  of  1 5.625  mVnode 
(corresponding  to  1 6  nodes  in  a  ,500m  x  5()0tn  grid). 


figures  5.2-12  and  5.2-1.^  show  that  WdSPF  scales  much  better  than  PTMP  as  the  number  of  nodes  increases. 
.Also,  we  see  that  PIMP  scales  better  when  the  network  is  less  dense.  When  the  node  density  is  kqti  static  (the 
simulation  area  is  scaled)  as  ilie  number  of  ncsies  increases,  the  overhead  is  almost  half  as  much  at  36  nodes  as  when 
the  node  density  is  scaled  (simulation  area  is  kept  static).  I  his  is  because  there  are  fewer  adjacencies  to  be 
maintained  in  a  sparse  nclwnrit 

1  he  opposite  is  true  tor  W(JSI’l-,  however,  it  ts  difficult  to  see  the  difference  with  the  figure  scale.  Here  the 
overhead  increases  when  the  network  is  sparse  because  almost  every  node  must  be  an  MPR  So.  optimized  flooding 
becomes  classic  broadcast  flivxfing  Wlicn  a  network  is  dense  inost  traffic  is  flooded  only  once. 

1  he  delivery  ratio,  shown  in  Figure  5i2. 1 3.  with  scaled  wxfe  density  stays  about  the  same  because  the  number  of 
h('ps  to  reach  a  nc'dc  slays  abc>ul  the  same.  In  the  sialic  node  density  scenario,  the  numfier  of  hops  consistently 
increases  as  the  simulation  area  increases  The  increase  in  area  leads  to  the  possibility  of  more  partitioned  nodes  or 
had  routes.  1  he  PTMP  ifelivery  ratio  approaches  zero  after  the  overhead  reaches  a  po  .it  of  swamping  the  network. 
Here  we  see  a  key  problem  with  PTMPs  method  of  exchanging  routing  information. 
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ht):urt  5  2-}  i  thtrJit  aj  obiamt’d  in  QualW't  uhen  Mulinf;  the  number  of  routers  in  the  network,  with  timers. set  on 

1 0  .second  intervals 

5.3  <>lh«r  wirekift  OSPFv2  tesi* 

1  Jic  ifMs  described  in  Sieititm  5.2  were  used  Ui  characien/e  perfi>nn<iiK:e.  Tlie  ft>iktwin|!  set  uf tests  was 
pertoimed  to  validate  the  correct  operation  of  the  implementation. 

1'esl  nainr;  HeteroKneous  Network.  Single  Area 

Objeettvrs:  t'onfirm  the  operation  of  edge  (routers  with  more  than  one  interface  with  one  being  wirelessl  routers, 
ihi-  correct  handling  of  heterogeneous  links,  and  routing  in  a  multi-path  environment  in  a  single  OSPI- v2  ate.ii 

Kquipmrnt  used;  /V  shown  in  Figure  5  3-i,  14  routers  with  Ethernet  interfaces  are  connected  to  the  mobile 
network  emulator,  and  two  of  these  routers  arc  further  connected  to  routers  A  and  B  ic^'clively  using  a  cross  over 
t  thernct  cable  Rouler.s  A  and  B  are  interconnected  by  an  f  thcrnci  cable  that  is  bandwidth  timiied  by  I  inux  Iraftic 
(.'ontful  I  K  I.  1  wo  end  users  (source  and  sink)  generate  UDP  traffic  and  are  attached  to  routers  A  and  B. 


Network 

Emulator 


blfcure  (  i  /  Ueu  rofieneous  St  twork 

Test  proredurec  I  inu*  I  f  traOic  control  limits  the  data  rate  hciwecn  ruuiers  A  and  R  to  Sftkbps  IJDP  traffic 
was  sent  from  sink  to  source  at  1 2kkps  f  )SPFv2  was  used  on  each  router  using  the  wireless  inUTfaccs  on  the 
nioHilr  network  I  he  low  bandwidth  link  was  assigned  a  link  metric  of  l(K>  and  all  other  liiAs  a  cost  of  I . 
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Three  tests  were  run  and  the  delivery  ratio  was  calculated.  The  first  test  consisted  of  partitioning  routers  1  and  14, 
so  all  trafllc  was  forced  over  the  low  bandwidth  link.  Second,  the  low  bandwidth  link  was  brought  down  and  a 
inulti-h<>p  path  was  created  on  the  wireless  network.  Third,  the  network  emulator  was  given  a  mobility  script  where 
node  I  and  14  would  be  partitioned  at  times  and  low  bandwidth  was  in  the  up  stale. 

Measurements,  data  processing,  and  outcome:  The  edge  routers  appropriately  handled  the  inclusion  of  point- 
to-pomt  links.  OSPl  v2  directed  most  traffic  through  the  high  bandwidth  mobile  network  when  it  was  available. 

F  igure  5  3-2  illusr-aies  the  user  data  packer  delivery  ratios  In  test  I,  the  low  bandwidth  link  could  only  handle  half 
of  the  load,  so  the  delivery  ratio  was4<)“/o  In  test  2,  the  delivery  ratio  was  IflO'/iihecausc  OSPF  was  able  to  route 
through  the  wireless  network,  which  was  only  partially  loaded.  A  protocol  such  as  OLSR.  that  cannot  assign  link 
metrics,  directs  traffic  through  the  low  bandwidth  point-t<vpoint  bwaase  it  is  the  shortest  path.  This  would  lead  to 
the  delivery  ratio  found  m  test  I .  Finally  in  lest  3,  the  delivery  ratio  was  82®.o.  Traffic  went  over  the  w'ireless 
network  unless  there  was  a  network  partition.  Packets  were  either  dropped  due  to  re-routing  time  or  queue  drops 
over  the  low  bandwidth  link 
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T'mI  name;  Multi rarca  operation  using  Wirelevi.QSP]  y2 

Objectives:  t.'i  nfimi  that  wireless  f)SPFv2  network  can  operate  in  .n-uSti  area  environment,  and  that  I  inux  and 
t  iss  o  routers  are  interoperable 

Lquipment  used:  Sixteen  I  mux  routers  with  f  themet  interfaces  were  connected  to  iJie  network  cmclator,  tlirce 
<.'isv(i  louteis  wcK-  connected  .ii  senes  with  Uie  etuulaicd  routers  as  sIhsw'ii  m  I  igurc  5.3-3,  and  two  end  users  were 
usi-d  as  data  viurccs  and  sinks  f.ach  of  the  l.inux  routers  were  configured  with  the  wireless  ( ISPF  interface  type  on 
ihe  emulator  Routers  I  and  15  were  additionally  configured  with  broadcast  interfaces.  All  l.inu.x  routers  interfaces 
were  set  to  Area  I 
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Figure  5  J-)  Multi-tuea  operation  with  wirelexs  network.! 


Tf*t  procedures;  Routing  tables  and  LSA  databases  were  checked  to  see  tf  routing  was  being  done  comxtiy 
I  rartic  was  sent  ftiitn  source  to  stnk  The  Mobility  emulator  was  run  for  a  random  moiNiity  script  to  see  if  iwoutinp 
was  d''nc  correefb. . 

Measuremeuts.  data  processing,  and  outcome; 

Wireless  OSPF  was  shown  to  work  properly  in  a  multi-area  environment,  and  it  intenoperated  with  Cisco  routers. 
All  routing  tables  and  ISA  da'abase  were  correct.  T raflic  was  successfully  routed  from  source  to  sink  and  rerouted 
when  the  wireless  netwt'rk  (  hanged 


lest  name;  Stub  I SF  with  multi-area  and  multi-^SSTAult'noiisous  SystemJ 

Objectises;  Show  tliai  wirclcs.s  OSPF  can  he  used  in  a  mulii-AS  network,  and  that  wireless  OSPF  can  be  used  in 
a  stub  wireless  format  that  reduces  routing  overhead 

l.quipment  used;  Same  as  in  the  multi  area  test  without  the  OOP  source  (Figure  5.V4). 


ASO-OSPF__-^ 

Figure  t  .1  a  Mulii  AS  ope  ration  with  wireless  network 

l  est  procedures;  I  he  network  is  setup  the  same  as  the  previous  test  Area  I,  whichafdifwifefcssiielwoA.  attd 
.Area  0.  consisting  of  two  of  the  Cisco  routers,  cotnpnse  Autonomous  System  0  Area  Son  the  Cisco  nwicrs  is 
brought  down  and  replaced  with  the  RIP  routing  proKKol.  to  form  another  AS.  Aulononatus  System  i  OSPI  is 
redistributed  into  RIP.  and  RIP  is  rcdisinbjted  into  f  )SPF  on  the  middle  router,  which  tm-cs  as  ait  Aumminiwis 
System  H»»rder  R»*uier  (,ASBR)  The  ed^e  l.inus  router  possessing  Soih  a  wiicle.ss  and  wired  interface  is  cortllg.urcd 
as  tfic  driauli  router  tor  the  wireless  network  by  senmg  the  "SiubWireles*  "  parameter. 

1  he  test  consisted  of  momn  nng  the  I  S.A  databases  and  routing  uhles  in  llie  routers  conetliwss  In  a  stub 
wircitss  network,  only  1  SAs  from  routers  in  the  wireless  should  be  present  m  the  I.SAdilabases  Host  was  set  to 
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ping  l.mux  router  1  while  the  wirele>s  network  was  in  motion.  The  stub  wireless  network  was  checked  for  a  default 
route  t<»  the  outside,  and  the  Cisco  were  checked  for  routes  to  nodes  in  the  wireless  network. 

Mostiremcnis,  data  processing’,  and  outcome: 

Operation  in  a  muhi-A.S  network  was  successful.  AS  Rxicmal  LSA.s  were  generated  by  the  Cisco  bordering  the 
autonomnu.s  systems  and  the  I.SA  were  disseminated.  Routers  in  the  stub  wireless  network  were  successful  in 
reducing  overheat  yet  still  maintaining  connectivity  to  the  outside  by  creating  default  routes  to  router  It-,  fcach  of 
the  wireless  routers,  except  router  1ft.  contained  only  LSAs  from  within  the  wireless  network  so  overhead  was 
reduced  All  routing  tables  were  checked  and  were  cotrccl  1  he  pmg  sent  from  Host  w'as  successfully  sent, 
received,  and  rerouted  when  necessary. 


Test  name:  l■MultlplcJnterf«:es  ftwe  wjred,.fwn_yMrcless) 

Objectives;  Show  that  a  Linux  router  running  ospfd  can  run  multiple  wireless  and  wired  interfaces  on  ths:  same 
router. 


(,4)uipmeni  used:  Simccm  I  mux  r^•ulc^^  arc  umncLicd  to  iIk-  network  emulator.  Two  of  the  Linux  routers  arc 
a!st>  on  an  1102  I !  woreless  network.  Additionally,  there  arc  p«nnt-to-poir.t  links  as  shown  in  f  igurc  5.3-5. 
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hy,u'c  5  t- 1  Ospfil  router  m  uh  two  wirelt\%  interfaces  and  two  wired  interfaces 

Test  procedures;  (  heck  that  Linux  router  2  has  the  right  information  in  its  I.SA  database  and  that  LSAs  arc 
distributed  correctly  In  addition,  the  point-t(»- point  wired  links  were  broughl  up  and  down  and  a  network  emulator 
mobility  •u.npl  wa.s  run  I  he  routing  tahic  was  chcckcst  as  links  were  varied  for  correctness. 


Measurements,  data  processing,  and  outcome: 

Coirecl  opeidiion  was  verified  fo:  I  iiiux  router  2.  All  I  SAs  were  geiicraled  and  distributed  correctly  As  links 
were  broUf’ht  up  and  down,  rerouting  func’u'ned  properly 


I  esi  name:  Ab  opaque  iJisscmtnalion 

Objectives:  Show  that  ospfd  with  when  running  a  wireless  interface  is  able  to  dis.scminaie  opaque  L  SAs. 

tquipmeni  used:  Sixteen  Linux  routers  on  the  network  emulator  and  two  additional  routers  connected  by 
Lihemet  as  shown  in  big'iire  5  1-h  Zebra  riHiiing.  software  versum  0  'f}b  is  installed  and  configured  tm  one  of  the 
Linux  riHifers  (shf'wn  in  Figure  5  3-ft) 
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Lmu*  router 
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Nehnor' 
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f  'ljtun’  5  i-6  OiHitfue  I.SA  dinsi'minatinn 

Test  procwlurM:  The  Zebra  OSP!  daemon 's  configured  to  support  MPI.S-TE,  Traffic  Engineering  exlcnsioiis, 
wtiivh  arc  disseminated  viaT>pc-10<)p3iiuc  ISAs  Each  of  the  routers  ISA  databases  will  he  checked  to  tenfy 
that  the  type  10  1„SA  is  present. 

Measurements,  data  pr'Kessing,  and  outcome:  1  he  dissemination  of  Type- 10  Opaque  LSAs  was  verified 
thriiughixit  the  enure  wireless  network. 


5.4  hummary 

I  his  section  has  dcst  rihed  our  tesiing  results  for  the  wireless  interface  type  We  (Gained  good  agneemenl 
between  implementation  and  simulation  results  In  addition,  wt  observed  the  followtr.g  characteristics  when  testing 
the  implementation 

<  Multicast  operation  over  8(12. 1 1  interfaces  has  seseral  problems  that  could  not  be  addressed  m  the  scope  o! 
this  contract.  We  list  a  few  of  the  problems  we  discovered  here.  KuM,  when  a  wireless  node  decides  to  join  a 
group  It  issues  an  KIMP  join  an  if  mtrrface  Every  router  in  radio  range  that  receives  this  message  then 
creates  a  group  membership  1  S,5.  so  the  router  can  distribute  traffic  to  the  sink.  The  IGMP  mechanism  was 
designed  fi  r  w  ired  networks  in  which  many  unnecessary  routers  do  not  receive  the  IGMP  join.  Second, 
nrjtiicast  rouieing  entries  wore  created  tor  wired  links.  I  he  rouiirg  entry  gives  input  and  output  interfaces  for 
a  particular  multicast  group  When  packets  arc  handled  like  this  on  a  wireless  network,  the  muting  entry 
input  a  id  output  interfaces  are  the  same  1  his  leads  to  packets  being  caught  in  routing  Ux'ps  that  repliciiie 
packets  until  they  reach  their  mas  IT! .  This  will  swamp  a  network  unless  TIT.  isset  sulficicnlly  lowfthis  is 
a  hack  u*  make  if  work  for  small  networks)  or  a  cache  is  kept  at  each  node  that  wilt  only  send  the  same  pac  ket 
once 

c  I 'Sing  multiple  copies  of  vmw  are  on  one  physical  machine  causes  lag  for  each  virtual  machine  Access  to  the 
real  time  clock,  is  av  ailabte  to  only  one  of  the  virtual  machines  at  a  time,  so  time  runs  at  a  different:  rate  on  the 
other  virtual  machines  This  causes  time -dependant  applications,  such  as  ilic  OSPF  daemon,  to  behave  slower 
than  iKirmal 

T  he  c^ability  to  have  multiple  f  >SPf  areas  within  the  same  wireless  network  has  not  been  implemented, 
because  the  spetificatnm  for  :ntcr-area  w  ireless  routing  has  not  been  defined.  In  all  of  the  tests,  the  wiivlrss 
network  is  treated  as  a  single  area,  w  hich  is  capable  of  connecting  to  other  OSPF  areas  A  w  ireless  edge 
router  cannot  ai  this  time  be  an  area  border  router 

•  t  I  o  obtain  statistics  on  link-layer  errors  m  the  physical  layer  of  wirelcvs  802. 1  Ih  drivers  on  Linux,  one  must 
pul  the  driver  in  a  special  momionng  mode  In  monitoring  mode,  the  driver  can  only  receive  network  packets 
but  m»t  transmit  so  n  is  not  p,issihle  to  uiiti/e  this  capability  while  running  OSPe  Ihis  limns  the  type  of 
link  layer  ntUifKam  ns  that  tan  be  provided  lo  OSPF  lo  tlie  signal  to-noise  ratio  ofa  link  The  drivers  can 
only  monitor  the  radio  noise  level  of  a  maximum  of  eighi  peers 

We  an'H  ipaie  perftirming  some  additional  development  on  the  wireless  interface  type  during  the  ONR  KSA I NC 
Hlo^k  program  Specific  areas  of  interest  include  optimizations  for  handling  e.xternal  I  S.As,  an  acknowTedgincnl 
inechanisin  for  a  subset  of  I  SA  fl»*iidinp.  and  adaptive  protocol  mechanisms  (link  metrics,  timer  intervals,  etc,). 

I  his  work  has  been  submitted  to  the  II  1 1  lot  consideration  (ilraft  spagiKi|o-maiirt-ospf-wireIess.interfacc-(Hi  txt). 
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6  DSCP-bascd  routing 

<  Hir  tuo  main  objectiws  in  DSC'P-based  routing  testing  were  to  (i)  test  the  ability  cf  the  routers  to  build  DSC  P- 
spccific  routes,  (ii)  test  the  ability  of  the  DSC'P  hased  routing  evtersion  to  inletoperale  with  legacy  routers,  an»l  (iii) 
test  the  interoperability  of  DsCP-based  routing  with  DSCP-bascd  .scheduling. 

6.1  Test  results 
1  est  name;  Mu|iix'|e  ()j>CPjjajh_s 

Objectives;  Confimi  the  correct  operation  of  uiiicas:  DSC?  routing  aiul  that  the  proper  route  is  created  for  each  of 
lour  f)St  P  codcpoinis 

F.quipment  used:  Nine  I  .iriux  rouierv,  iwo  irafTic  sources  and  a  trafbc  sink,  and  a  timeserver  to  synchntnire  all 
tile  cl'K  ks  Used  in  this  tC'-l  The  network  tormaiion  is  shown  in  Figure  6  1 . 


/■'if'ute  f>  !  MiiUipU  DSCPpaih\  tesi  i-onfiyuralion 


lest  procedures;  Farh  of  the  routers  were  configured  with  broadcast  interfaces.  Fink  metrics  were  assigned 
costs  aceotding  to  Uic  calues  found  ui  Fable  6- 1 .  All  router  interfaces  not  found  in  the  table  were  assigned  a  cost  of 
one  for  all  DSC  P  \alues  I  he  cost  assignments  were  set  so  trafl'ic  of  DSC  P  type  Itxe  would  be  dirccicd  through 
slacc  1,  typs  0x8  liirough  slaxe  2,  type  0x4  through  slaved,  and  type  0x0  through  slavc4  Using  MGF;N.  Scooter 
sent  four  times  of  UDP  traffic  to  Skinny  1  he  flows  were  .assigned  DSCP  values  0x0.  0x4.  0x8.  and  Oxc. 
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Routsr 

Interface 

OSCPOxO 

0SCP0X4 

whtiiim 

Datagram 

1 

1 

10 

1 

10 

2 

1 

1 

10 

1 

Stanley 

0 

1 

10 

1 

10 

1 

1 

10 

10 

2 

10 

1 

10 

to 

3 

10 

1 

t 

10 

Surplual 

0 

1 

1 

10 

1 

I 

10 

10 

1 

to 

wzsnm 
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10 

1 

1 

10 

Siavel 
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1 

10 

10 

10 

1 

1 

10 

10 

10 

Slave? 
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10 

1 

10 

10 

f 

10 

1 

10 

to 

staves 

0 

10 

10 

1 

10 

1 

10 

10 

1 

10 

Slave  4 

0 

1 

1 

1 

1 

1 

10 

10 

10 

1 

Apollos 

1 

1 

10 

10 

10 

2 

10 

1 

10 

10 

3 

10 

10 

1 

10 

4 

10 

10 

10 

1 

Table  6- 1  Link  mclrics  assigned  to  routers  in  Figure  6- 


(apcctfd  outcome:  Unicast  data  packet^  from  source-,  scooter,  to  sink,  skirmy.  should  he  routed  via  four  distinct 
paths  assipnod  by  the  DSC'I’  codepoint.s 

Measurements,  data  processing,  and  outcumer  Network  routing  tables  were  periodically  dumped  and  the  tables 
niatcta-d  the  expected  outcome  I  cpdump  was  run  on  the  routers  manager,  .surpiu.sl  .  and  slave  I  through  4  and  the 
^  •'til  c*  USC'P  irafik-  was  being  forwarded  on  the  correct  routers.  In  addition.  Insure  w'as  run  on  Datagram  and 
M.snaj»et  i<»  lest  the  erwle  on  .s  single  area  muter  and  an  an-a  border  router  All  tests  performed  by  Insure  were 
passed 


Test  name:  l)Sf 'P  mtetopcrabiljiy 

tibjectlscs:  Confiim  the  correct  operation  of  unicast  USCH  routing  in  a  edge  routing  environment. 

Equipment  used:  I  'lghi  I  inux  routers,  one  Cisco  router,  one  traffic  siturce,  and  two  traffic  sinks  are  connected  in 
the  formation  of  figure  6-2 
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Figure  f.  2  Multiple  DSC/' paths  test  configuration 


I  e»i  procedures:  The  routers  are  configured  with  the  same  costs  used  in  Figure  6- 1  above  except  the  Cisco 
router’s  interfaces  can  only  be  assigned  a  cost  for  DSCP  0x0.  The  Cisco  router  was  as.signcd  the  same  cost  that 
Datanrain  was  assigned  for  DSCP  0x0,  Using  MflEN.  Skinny  sent  four  flows  of  UDP  traffic  to  Scooter  and  l  abl . 
The  flows  were  assigned  DSCP  values  0x0, 0x4. 0x8,  and  Oxc. 

Expected  outcome:  Unicast  packets  from  Skinny  to  Scooter  should  he  routed  via  a  DSCP  0x0  path  since  the 
C.'isco  router  does  not  support  TOS  based  routing.  Unicast  DSCP  enabled  packets  from  Skinny  to  Labi  will  be 
routed  according  to  the  DSCP-enabled  routes  since  a  path  of  all  I-inux  neuters  can  be  formed. 

.Measurcnieiils,  data  processing,  and  outcome:  Network  routing  tables  were  pcnodically  dumped  and  the  tables 
matched  the  expected  outcome  Tepdump  was  run  on  each  of  the  i.inux  routers,  and  the  correct  traffic  was  being 
torwarded  on  these  routers  1  ms  test  worked  as  planned 

Test  name:  DSCPjnieropcrabiJity  ycith.mixcd  DSC  P. enhancement 

Objectives:  Co.nfirm  the  correct  operation  of  unicast  DS(?P  routing  in  a  edge  routing  environment  when  the  Linux 
routers  have  bien  enabled  to  u.se  DSCP  0x0  as  a  DSCP  value  on  non-DSC'P  loutcrs. 

Equipment  used:  I  hc  network  configuration  is  identical  to  Figure  6-2. 

l  est  procedures:  The  routcis  are  configured  with  the  same  costs  used  m  Figure  6-1  above  except  the  Cisco 
router's  interfaces  can  onl\  be  assigned  a  cost  for  DSCP  0x0  The  Cisco  router  was  assigned  the  same  cost  that 
I  )aiagram  was  assigned  for  DSf  P  0x0  E  ach  of  tlie  Linux  routers  were  configured  in  allow  mixed  metrics  mode  so 
DSCP  routing  can  be  used  with  a  C iscn  router  The  following  procedure  was  run  when  all  interfaces  w'crc 
configured  to  broadcast  and  then  repeated  with  all  interfaces  configured  to  point-to-point. 

Expeeted  ouleome:  I  'nicasi  packets  from  Skmny  tc)  Scooter  should  he  ri'tiied  using  DSf  P  routes  The  DS(  P 
V  alufs  for  0x4,  0x8.  and  Oxc  on  the  Cisco  router  should  appear  to  be  set  to  the  DSCF*  0x0  value. 

.Nleisuremenis,  data  processing,  and  outcome:  Network  routing  tables  were  periodically  dumped  and  die  tables 
matched  the  expected  outcome,  Tepdump  was  run  on  each  of  the  Linux  routers,  and  the  correct  traffic  was  being 
forwarded  on  Uiese  roulris.  This  test  worked  as  planned 

l  est  name:  .Multi-area  liberation  using  DSCP 
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C)bjeciiv*«:  Confinn  DSCP  DSPFv2  functions  correctly  with  multiple  areas  when  interfaces  are  set  to  broadcast, 
poini-to-point  (pp),  non-broadcast  multiple  access  (idima),  point-to-multipoint  Ipimp),  and  point-to-multipomt 
multica.st  (piinpnicasO. 

I^uipmenl  used:  Nine  Linux,  routers,  a  traffic  source,  and  two  traffic  sinks  arc  cwnected  as  shown  in  Figure  h- 


hgurt-  6  .1  Multi  urea  >iiH‘ralum  uung  fASCf" 

Test  procedures:  flic  rouiets  ui  Figure  6-3  were  coiifigurcJ  with  tlw  DSCP  tiaianieicrs  slaiwn  in  fable  6-1,  All 
interlaces  that  are  not  shown  were  set  to  one  for  each  of  the  four  DSfP  values  Fleven  virtual  links  were  configured 
because  Manager.  Sianlcy.  and  SuiplusI  arc  non  backbone  area  border  routers  (ABRi.  Ihc  virtual  link 
configuration  is  show  in  Table  6-2. 

Mfil  N  was  used  to  generate  four  flows  of  CBR  traffic  from  skinny  to  each  of  the  sinks;  Packet,  labt.  and 
Scooter 

Ihi-  same  procedure  was  perfr'trncd  on  bioarkast.  pp.  nbma.  pimp,  and  pimpmeast 


ABH 

Link  End  Points 

Stanley 

Slavel,  Slave2,  Manaqer.  Surplusi 

Manaqer 

Slavel .  Siavc2,  Slave3.  Slaved.  Stanley,  Surplusi 

Surplus  1 

Slaves.  Slaved.  Manager,  Stanley 

Table  6  2  Virtual  hnks  eunfigured  in  Figure  6  2  S 


Ltpvcied  iiutfome:  The  summary  I  SAs  exchanged  between  areas  should  enahlc  BSC’P  based  routing  to  take 
place  between  Ihc  areas 

Meistiremenls.  data  processing,  and  outcome;  Network  routing  tables  were  dumped  on  eadi  of  the  routers  and 
compared  t<  the  expected  outcome.  1  he  routing  tables  were  correct  for  each  of  the  foiff  DSCP  values  tcir  each  of  the 
5  interface  types  Tepdump  was  run  on  the  incoming  interfaces  of  selected  rouierv,  <Mid  il  was  determined  that  the 
corrcti  tralfic  was  being  forwarded  on  these  routers  In  addition,  Jnmre  was  run  on  Datagram  and  Manager  to  test 
the  cisie  on  a  single  area  router  and  an  area  border  router  All  tests  performed  by  Insure  weriepa.s.scd. 


1  est  name:  Multi-area  operation  using  DSC  P  with  mixed  njetpes 

CMiJcctIves:  Ctinfinn  DSCP  OSPI  v2  functions  correctly  with  multiple  areas  while  some  routers  have  partial 
DSC  P  costs  defined 

KRuipment  uwd:  The  network  c.mfigutaiion  is  shown  in  Figure  6-3. 
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Feil  procedures;  The  routers  in  Figure  6-3  vkerc  ccniigured  with  the  DSCP  parameters  shown  in  Fable  6-3.  All 
intcrt'accs  that  are  not  shown  were  set  to  one  for  each  of  the  four  IJSCP  values,  fcntncs  in  Table  6-3  that  contain  a 
"X"  were  not  defined.  Eleven  virtual  link.s  were  configured  because  Manager.  Stanley,  and  Surplusl  are  non- 
backbone  area  border  routers  (ABR)  The  virtual  link  configuration  is  show  in  Table  6-3. 

1  his  procedure  was  perfonned  when  interfaces  were  configured  as  broadcast  and  ptmpmcast. 


Routor 

Intarfaca 

DSCP  0x0 

DSCP  0x4 

DSCP  0x8 

DSCP  Oxc 

Oatageam 

1 

1 

10 

1 

10 

2 

1 

1 

10 

1 

Stanley 

0 

1 

10 

1 

10 

1 

1 

10 

10 

10 

2 

10 

1 

10 

10 

3 

10 

X 

1 

10 

Surplusl 

0 

1 

1 

10 

1 

1 

10 

10 

1 

10 

cEisna 

0 

10 

X 

1 

10 

Slaval 

0 

1 

10 

10 

10 

1 

1 

10 

10 

10 

Slava2 

0 

10 

1 

to 

10 

t 

10 

X 

10 

10 

Slaves 

0 

10 

10 

1 

10 

1 

10 

10 

1 

10 

Slava  4 

0 

1 

1 

1 

1 

1 

10 

10 

10 

1 

Apollot 

1 

1 

10 

10 

10 

2 

10 

X 

10 

10 

3 

10 

10 

1 

10 

4 

10 

10 

10 

1 

Table  6.2-3  Link  merries  assigned  to  routers  in  figure  6  2-3 


Ltpeeted  outcome;  Routing  table  entries  for  DSC'P  0,  tt,  and  12  should  remain  unchanged.  .Any  DSCP  0x4  route 
iliat  would  have  used  link  168  50or  192.16H  3  4  should  he  rerouted  and  a  DSCP  0x4  route  to  192.168.5.0  and 
192  16S  3  4  should  not  be  created 

Measurements,  data  processing,  and  outcome:  Network  routing  tables  were  dumped  on  select  routers  and 
comp.ircd  to  the  expected  outcome  The  routing  tables  were  correct  for  each  of  the  four  DSCP  values  for  broadcast 
and  ptmpmcast. 


lest  name:  DSCP-bascd  multicast  rinitmg 

Objertises;  Confirtn  operation  of  MOSPf  with  DSCP. 

fc4|uipment  used;  Tnc  configuration  shown  in  Figure  6-1  was  u-sed  to  test  multica.st  routing  in  a  single  area 
contiyuraiion 

Test  procedures;  DSC  P  metrics  were  assigned  to  the  links  in  Figure  b- 1  per  Table  6-1 .  All  interfaces  not 
defined  in  the  table  were  assigned  a  value  of  one  for  each  DSCP  Only  broadeasi  interfaces  were  tested  in  this 
configuration 

Multicast  traffic  was  onginated  from  Skinny  using  MGFN.  Mullica.st  receivers.  Packet,  l-abl,  and  Scooter, 
lespondcd  to  ItiMP  queries,  leading  to  the  I  mux  rtnitcis  onginatiiig  group-nieinbership-LSAs.  Multicast  tratfic  was 
first  onginaied  with  no  DSCP  markings,  and  the  routes  taken  were  obsened.  Nc.xt.  the  muHicasi  caches  were 
flushed  fioni  all  the  routers  and  the  tests  were  repeated  with  Skinny  originating  DSCP  0x4.  Finally,  thi.s  procedure 
was  rcpe.ited  for  DSCPs  0x8  and  Oxc 

Expected  outcome;  I  he  ptesence  of  DSCP-based  metrics  should  enable  the  multicast  tree  to  be  built  for  a 
particular  DSCP  value  Figure  6-5  shows  the  multicast  trees  that  should  be  huilt  for  each  or" the  four  DSCP  metrics. 
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Figure  li- 5  Multicast  routing  tree  for  the  fourDSCP-baieJ metrics 

.Met$urem«nts,  data  prorrsaiag,  and  oatcome:  Multicast  routmj;  cache  entnes  were  dumped  at  each  of  the 
rtmiers,  and  the  mutes  matched  the  expected  outcome  and  the  multicast  tree  was  correct  Tepdump  was  run  on  the 
incon’inp  interfaces  of  s»‘let  led  rsHiiers,  and  the  ciMTcct  traflk  was  heing  forwarded  on  thes»'  rouiers  Also,  each  of 
the  multicast  sinks  received  the  multicast  data. 


I e»l  aaror:  psCP-,lM|.sed  multicast  routinj^  wjtli  nuxedjiKtrjcs 

Objectives:  Confirm  DSCH  MOSPI-  functions  correctly  while  some  routers  have  partial  DSCP  costs  defined 

l^uipmeat  used;  1  he  configuration  shown  in  F  igurc  h- 1  was  used  to  test  mixed  nicinc  multicast  routing  m  a 
single  area  configuration 

I  e*t  procedures;  t  he  routers  in  Figure  h-3  were  configured  with  the  I>SC'P  parameters  shown  in  Tabic  <>-4  All 
intertaccs  that  are  not  shown  were  set  to  one  for  each  of  the  four  DSt  P  values.  Lniries  in  I  able  h-4  that  contain  a 
"X"  were  not  dcfiiK-d  l  levrn  virtual  links  were  configured  because  Manager.  Stanley,  and  SurplusI  arc  non- 
hackhme  area  tx>rdrr  rcMiters  ( AHR  |  1  he  virtual  link  v.f'nfiguraiim  ts  show  in  1  able  t*-3  Ibis  procedure  was 
performed  when  interfiKCs  were  configured  as  broadcast 
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Table  6  4  Link  metrics  assigned  to  routers  in  f  igure  6.2- i 


pectcd  ontcomr:  Routing  taWe  enincs  for  DSCP  0. 8.  and  12  should  remain  unchanged.  Any  DSCP  Oxc  route 
that  would  have  used  link  192.  I^>H  5  4  should  he  rerouted  and  a  DSCP  Oxc  route  to  192.1h8.5.4  should  not  be 
treated 


Measurements,  data  processing .  and  iMifeome:  Network  routing  taMes  wore  dumped  on  select  routers  and 
tompared  to  the  expected  outcome  The  routing  tables  were  conect  for  each  of  tlic  four  DSCP  values. 


Test  name:  Multi-area  multicast  operation  using  DSCP 

Objectives;  (.  onfirm  DSCP  MOSPI  functions  correctly  with  multiple  areas 

Kquipment  used:  i  igure  6-3  displays  the  equipment  configuration,  with  multicast  source.  Skinny,  and  group 
members.  Packet,  lab  I,  and  Scooter 

Test  procedures;  I  he  network  was  configured  idcmicalty  to  the  MuLti-irea  operition  using. DSCP  test 

Kxperted  outeomr;  IX-.spilc  the  fact  that  route  summarisation  occurs  across  area  boundanes,  multicast  routing 
should  take  into  account  the  DSCP  metnes  in  compulation  of  shortest-palh  trees  Figure  6-5  shows  the  multicast 
trees  that  should  be  built  tor  each  of  the  tour  DSCP  metncf 

Measurements,  data  processing,  aad  nutcome;  Multicast  routing  cache  entries  were  dumped  at  each  of  the 
routers,  and  the  routes  matched  the  expected  outcome  and  the  multicast  tree  was  correct.  Tepdump  was  run  on  the 
incoming  interfaces  of  selected  rooters.  ar.d  the  correct  traffic  was  being  forwarded  on  these  routers  Also,  each  of 
the  tnuliicasi  sinks  received  the  multicast  data  The  tests  were  passed  for  each  of  the  5  interface  types. 


Test  uame:  Wireless  and  psCf’.OSPFv^ 

Objectives;  Confirm  interoperability  of  W  ircless  <>SPF  v2  and  t)SC  P  routing  (both  Boeing  nyHlifications 
operating  simullancousiy) 

kquipment  used;  We  wall  reuse  the  configuration  shown  in  Figure  6-2  above 
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T«t  proeediircs:  Tlic  networii  will  configured  as  in  Figure  h-2  md  Wiretes#  OSPFvl  vmll  he  used  as  die  routing 
jwotcKol  I  wo  fltiws  of  CBR  iraffic  will  be  sent  from  User  I  to  User  2.  Otte  flow  will  be  irewked  widi  DKCP  type  2, 
and  It  will  be  directed  across  the  low  bandwidth  link.  The  other  flow  with  DSCP  4  will  be  diPKted  to  the  wireless 
network  Network  connectivity  will  be  varied  to  verify  corretl  routing.  Similar  tests  will  be  conducted  with 
multicast  data  mid  multicast  routing 

Measurements  and  data  processing:  Network  routing  tables  will  be  periodically  dumped  and  post-processed, 
and  compared  against  the  expected  behavior.  1  cpdump  will  be  run  on  each  interface  mid  saved  to  a  log  file,  which 
will  he  posi-pr(Kessed  to  exnract  the  delivery  ratio  and  end-to-end  delay  of  ihe  user  traffic  based  on  tlie  DSf'P  type 
In  midiiion,  the  amount  of  overhead  generated  by  Wireless  OSPFv2  will  be  calculated. 

Cxpeetml  ontcome:  1  raffle  with  DSCP  type  1  should  uike  the  low  bandwkUi  hnk  wIkc  it  is  m  the  up  .state  and 
transition  to  the  wirele&s  network  when  it  is  in  the  down  state.  T  he  network  should  be  able  to  be  rtilc  to  obtain  a 
higher  delivery  raiio  than  obtained  m  ihc  Hs*?rQKfB?ou.s  Network  when  using  only  Wireless  <'>SPFv2. 


lest  name;  PSCP  mid  QpS  scheduhng^integralion 

Objeetives:  Confirm  interoperability  between  DSC  P-based  rouiing  and  built-in  Linux  DSC'P-based  packet 
(queue)  schedulers 

Kquipmrnt  nwd;  The  test  configuration  of  Figure  h- 1  will  be  reused 

Test  procedures;  User  I  sends  four  flows  of  C’BR  traffic  to  user  2,  Each  flow  is  assigned  a  different  DSCP 
value  I  ink  metrics  shall  be  arranged  such  that  the  different  flows  find  diflereni  paths.  In  addition,  certain  DSC  P 
codepoinis  will  receive  preferential  treatment  in  priority  queues 

Measuremenn  and  data  procettiag;  i  epdump  wilt  be  run  on  each  interface  and  saved  to  a  kig  file,  which  will 
be  post-processed  lo  extract  uiilizaiion  statistics,  and  queuing  priority.  Network  routing  tables  will  be  penodtcally 
tliimped  and  posi-privessert  and  compared  against  the  network  emulation  scenano 

Kxpecled  outcome;  Data  packets  from  users  1  to  2  will  be  routed  via  different  paths  according  to  (hem  DSCP 
ctHlcpoin*  In  addition,  wt  should  «ihscrvi-  flows  with  diflereni  DSCP  codepoinis  receiving  different  service  in  ihc 
quinies 

b.2  Summary  | 

1  his  section  has  described  our  testing  results  for  the  DSC  P  hased  dynamic  routing  We  observed  the  following 
characU'ristivs  when  testing  If.e  implementation 

<  Ihe  Linux  kernels  used  in  testing  were  pairned  lo  .support  all  DSCP  codepoini  values.  a.s  described  in 
Sectum  4  3  1  The  stock  kernels  that  ship  with  the  versions  of  Redllal  Lmux  that  wo  used,  along  with  the 
latest  kernel  available  from  kernel  org.  still  wse  TC)S  Values  for  routing.  Iinuiing  routing  emnes  to  eight 
possible  IDS  values  Patched  kernels  allow  all  64  possible  DSCP  values  to  he  used  for  routing  entries. 

i.  f  he  routing  suppo't  in  the  kcrr.el  for  multicast  traffic  docs  not  allow  multiple  multicast  routing  entries  for 

the  same  source  and  multicast  group  pair.  This  is  a  kernel  limitation,  not  an  inqifemcntation  limitation, 
•ml  we  did  nut  experiment  wiih  kernel  extensions  to  suppsirt  multiple  entries  per  sourec  ami  multicast 
group  pair 

I  his  implementation  leveraged  legacy  "  I  <  >S”  fields  m  Ihe  f  )SPI' v2  I  SAs  DSPFv3  for  IPv6  docs  net  siqiport 
these  fields,  so  DSf  F-based  metric  inlf'mtation  must  be  disseminated  in  additional  I.SAx  (web  as  opaque  I  hA 
types!  FunlaTmore,  it  spears  that  mutttca.st  protocols  must  be  extended  to  u.se  ihisc^iAiItty  if  Mf  )SPf  is  n<»l  the 
multicast  protocol  in  use  (specilieal'.y,  HIM  and  KiMP  may  need  modifitations  to  aiq^n  ditlercnt  rouang  based  on 
the  Dh(  P  value  in  Ihe  data  packets)  T  herefore.  while  this  impicmenution  i»  a  prwif-of-concepi  implcnrentaiion. 
liinher  proi.'icol  development  work  i«  needed  for  this  eapihihty  tc*  he  imptenKincd  in  IPv6  m  niuiticast  prolis.tils 
other  than  Ml  iSPF 
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7  Demonstration  results 

7.1  .Scope  and  objectives  of  demonstration 

(.)ur  demonsiration  attempted  to  meet  both  broad  program  objectives  and  specific  technical  objectives,  m 
demonstration  scenarios  that  map  to  NBN  operational  concepts,  as  described  below. 

7.1.1  Prucrani  objectives 

I  he  Boeing  (  omposite  Routing  program  docs  not  focus  on  technology  development  that  covers  all  aspects  of  the 
broad  operational  goals  identified  in  the  program  solicitation,  but  our  demonstration  program  was  designed  to 
leverage  off-the-shelf  components  in  the  areas  not  specitically  addressed  by  the  routing  protocol  implententation. 

I  able  t- 1  briefly  describes  how  NBN  Composite  Routing  overall  program  objectives  were  met  by  a  combmatiim  of 
off-the-shelt  hardware  and  software  components  and  tlte  new  routing  protocol  implementation,  and  provides 
pointers  to  later  subsections.  Sub-demos  are  described  in  Section  7.3. 


.NBN  Composite  Routhig  goal 


Demoostration  concept 


•  wirciest  OSPF  interface  type  enables  bandwidth- 


(i)  Any  onboard  IP  data  routed  to  any  j- — 


communication  link  (mcluding  I  ink 
lb)  based  on  the  latency  requirement 

(lit  automated  network  participation 
0  e .  leaving  and  joimng  a  network 
with  no  manual  tiperations) 


operation  on  multihup  wireless  networks 


DSCP-batcd  routing  allows  for  dynamic  policy 
rtwiring  for  load  balancing  and  QoS  control 

'  Note;  IP  over  I  ink  1 6  not  addressed  by  this  program 


tiK^ile  wireless  nodes  join  network  DHCP 

DHCP  authentication  via  RFC  31 IR 


(III I  all  traffic  authenticated  using 
either  network  or  application  layer 
secunty 


shivw  compatibility  of  protocols  with  TACl.ANi: 

I  surrogates  (IPsec  gateways^ _ _ 

•  all  router  messages  authenticated  using  MD5 
authentication 


(i\  1  automated  network  management 
and  dynamic  bandwidth  management 


host  auCheniicaiion  and  encryption  via  Host  Identity 
Protocol 


TiihU 


•  _ rouier  cortams  SNW^ornpatiblc  MIB  and  uw  aceni 

•  S^NMP  element  manager  for  deyjcejnoniionng  _ 

•  Note;  Dynamic  bandwidth  management  (above  and 
_  L_  beyond  dynamic  fouling)  not  addressed  by  thisjwogram 

Muppint'  I  if  program  goals  to  demonstration  concepts  Bold  font  indicates  main  program 

deliverables 


Relevant 

(uMemt^ 

'l,2.  4.  5  ” 


2. 

not 

a£pl!cablc_ 

475’ 

4.5 


2.  3. 4.  5 

5"“ . 

. 

Z 

not 

applicable 

software 


.1.2  I  echnical  objectives 


i  hi-  main  tcibnicai  obicciives  ol  the  demonstration  include 

111  demon itrate  the  correcitiess  of  ilic  ne*'  routing  protocol  impicmcniatinn  by  dyTiamieally  changing  the  network 

lopoiogv. 

till  compare  ihe  performance  of  the  legacy  ADNS  reuiing  protocol  (OSPI'v2)  agaiast  the  new  implementation; 
diul 

(iiii  illustrate  how  routcTs  based  on  our  extensions  can  inieropcraie  wath  legacy  equipment 
<  Kir  specifu  technical  objective'  are  shi-wTi  in  1  able  ''-2 
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Wireless  OSPF  dramaically  reduces  *  ^  I 

rowing  protocol  overhead  in  wireless 

networks 

•  Mipport  for  various  link  technologies  (satellite.  LOS,  2 

Show  operation  of  wireless  OSPF  h - - 

exteiKions  in  heterogenetws  network  »n««faees|  uperation _ 2 _ 

environment  *  •  multicast  compatibility  viath  wireless  OSPF _ _ 3 _ 

•  host  and  platform  mobility  compatible  with  OSPF  4.  S 

_ _  _  _ .  _ ,?!**hnj>^ _ _ _ _ _ _ 

•  show  load-balancing  of  unicast  traflic,  tncluding  2 

DS(  P-based  dynamic  routine  can  !  mixed  operatic  with  BOP  routers  * 

tniprote  Navy  load  balancing  show  multicast  operation  (MOSPl )  lor  notional  l  ink-  j  3 

_ _ _ _ _ _ _ ’  _  _ 

'  Cisco  TfCiP  routers  __  ^  2  _ 

lntct«»perability  T  •  sb(,v»,  wireless  and  DSCP  exiensions  working  •  2 

_ _ _ _ _ _ 1  stmulUneously  _  __  _ _ i  _ 

Tuhlt  7-3  Summaiy  of  technical  demnnstration  goah 

t.I..3  Metrics 

1  he  dcmonsirat'tm  and  expenmems  were  instrumented  ui  provide  real-time  or  post-processed  statistics  on  the 
network  p<-rformanre  Much  of  the  demonstration  was  focused  tm  displaying  a  new  capabiiity  (such  as  k<ad 
balancing)  rather  than  an  improvctnent  on  an  existing  capability,  so  we  did  not  have  a  quanntatne  metric  .^ssocl3led 
with  i.hcm.  fable  7-3  lists  tlic  quantiuiivc  mctric.s  iliat  were  measured  durmg  portions  of  the  demonstrations 
described  in  Section  5. 


inipro\e  Navy  load  balancing 


lntcf«»perability 


Metrfc 


DcHhMm 


t  onirol  overhead  i  Number  of  eentrol  hits  or  packets  (relating  to  routing  proioctti  operation) 

. . . ,  _ I  _ transmitted  dunng  the  demonstration  run  _ _  _  _ _ 

Packet  delivery  lafio  '  Ratio  ot  user  data  packets  sent  into  the  network  to  data  packets  received  by  the 

"  _ _ ^  destiitauon  nodes _  _ _ _ 

Routing  tcnvergencc  time  *  brtwccn  establishment  of  link  layer  conneclisaiy  and  IP  addressing  and 

I  fiH  data  jransfer  to  occur  _ 

Table  7  d  Tift  of  metru  <  measured  in  demonsiratsans  ami  experimcnlt 

7.2  laiegrated  Testbed  C'onlignrstioR 

Most  of  the  demoasirations  dev  nbed  in  Seciion  7.3  made  use  of  the  integrated  testbed  shown  in  Figure  7-2, 
designed  to  show  the  following  capabilities' 

•  operation  of  'wnreless  interface  type  cm  dCtual  wireless  networks  (support  for  various  link  techiK«logics. 
mixed  node  operation,  and  multicast  operation) 

•  operation  of  l>S<‘P-based  rouiinp  (including  an  operaiionally  relevant  DSt  P  marking  stmtepy.  load- 
balancing  of  unica^  irafTic  compatible  with  D(iP  routers,  and  multicast  operation) 

•  automated  miworti  participation  (leiivc  and joint 

•  traffic  authentication  and  set  uriiy 

•  auuHitdled  nelwoik  iiianagenienl 

•  inicropcrabiliiv  with  lepaev  rotters  and  bciwcTn  the  wireless  and  IfWP  extensions 
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F  igure  7-  i  provides  a  notional  representation  of  the  demonstration.  The  demonstration  testbed  highlighted  II' 
networking  between  ships,  over  satellite  links  and  via  ship-to-ship  wireless  networking.  Specifically,  the 
demoastration  highlighted  the  notional  concepts  of  preferential  dynamic  routing  of  JCA  traffic  over  Challenge 
Athena  (in  the  presence  of  in-line  encryptorsj,  range  exten-sion  of  I  ink- 16  over  the  ADNS  system,  and  multihop 
wireless  line-of  sightbeyond-line-of-sight  (l.OS'BLOS)  networks  supporting  host  and  platform  (ship)  mobility. 


figure  7- !  InlcgraleJ  testheJ  notional  concept 


ember  :i. 
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'  2  Inu-fitulfti  leslhfJ  etiuifimcnt 

I  igari-  7-2  illustrates  how  the  notional  concept  in  F igure  7- 1  was  instaniiafed  I  he  following  equipment  was  part 
»if  the  demonstration  tcsihcd 

•  l-inui  router,  I  .mm  routers  contain  one  or  more  wired  or  wireless  interlaces,  and  a  tnodilied  OSI'I  v2 
routing  daemon  Wired  interfaces  were  either  tlhcmet  or  serial  RS-dd*)  Ipoint-to-point).  W'lrelcss 
interfaces  were  either  It02  I  lb  or  an  Fthemet  interface  plugged  into  the  wireletsnetworit  emulatw.  A 
vanciv  of  ninspiites  were  used  as  routers,  including  iJell  Powerl-dgc  rackmount  servers,  I^II  fiptiplcx 
desktops,  cusiom-Niilt  PC's,  laptops,  and  iPAQ  handheld  computers 

•  (  iteo  router.  We  used  rwo  C  isco  Mobile  Access  Router  (MARt  routers  running  OSPFv2  «hI  RIP\2. 

•  hatelliir  timHlalor.  We  used  two  Adtech  SX  H  haritware  link  emwiafors  with  RH-440  interfaces 

•  I  raffle  tourcM/tioks.  I  liese  were  I  -inus-based  woi  kstations  running  traffic  pnctalion  utilities  such  as 
SRI  ’»  M<>FN  and  IP  hased  video  cameras  oi  display  programs  JCA  iratlic  was  reprvscnied  by  a  long 
tunning  If I'ttansfer 

•  f  2P  surrogate.  I  he  enhanced  (  '2?  in  the  ftiture  will  pemut  I  ink- |h  tracks  to  he  earned  over  AiJNS’s  IP 
infriistruciurc.  using  multicast  touting  For  demonstration  purposes,  we  did  nrt  Kitd  wnsor  tr,ack.s  but 
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•  ia<>(ead  used  multicast  v-ideo  from  a  single  source  (ship  ! )  to  multiple  receivers  (ships  2  and  3)  as  a 
surrogate  traffic  type. 

•  Encrypfor.  Our  original  plan  to  use  TACLANE  encryptors  was  no  longer  feasible  since  the  demonstration 
location  changed  to  San  Diego.  However,  we  con.structed  IPscc- based  gateways  that  arc  functionally 
equivalent  to  TACEANEs,  using  Linux  IPsec.  TACLANE  Release  LI  supports  IP  Type-of-Servtce  (lOS) 
bits  bypass,  and  the  DSCP  field  is  a  redefinition  of  the  TOS  field. 

•  Wireless  network  emulator.  We  used  the  Boeing  Synthetic  Network  Environment  (SNE)  as  the  wircle.ss 

emulator.  The  SNf:  runs  a  mobile  ad  hoc  emulation  script  that  emulates  the  conneclitaty  of  mobile  nodes 
W’hen  two  nodes  are  deemed  to  be  out  of  radio  range  from  one  another  in  the  emulation,  the  SNE  blocks 
packet  reception  from  one  another  respectively.  The  SNE  is  based  on  HRL’s  mobiemu  tool,"  and  has  been 
extended  to  also  support  bandwidth  limitation  and  packet  errors  or  (deterministic  or  statistical)  los.ses.  I  he 
mobility  scripts  are  created  through  the  use  of  CMU’s  scenario  generation  tool  (part  of  the  ns-3  Internet 
simulator)  and  can  be  run  at  different  speeds  to  effect  different  mobility,  t  i 

7.3  Demonstration  coHduri 

We  conducted  final  program  demonstration  on  September  18, 2(103.  in  Building  91  at  SPAWAR  SSC-.SD  Ihc 
tlciiii'nstratiCiii  consisted  of  five  “sub-denios  "  Ihc  first  was  a  focused  deriKinstraiion  of  wireless  routing  (Seciion 
7.3. ! ).  followed  by  several  demonstrations  using  the  integrated  routing  testbed  (Sections  7  3. 2-7.3 .5)  showing  both 
wireless  routing  and  DSC  P-based  routing  in  the  context  of  NBN  operations. 

7J.I  Wiretc««  routing  demoaatration  (Sub-demo  I) 

Thi.s  iJcmonstrafion  was  a  focused  comparison  of  the  performance  of  the  new  wireless  interface  type  for  OSPh  v2 
with  that  of  itic  legacy  Point-to-Miihipoint  interlace  type 

7.3. 1 . 1  Objective  and  expected  rexuitx 

i  ipcfiiiion  of  legacy  (jSPi  v2  over  multihop  wireless  networks  requires  configuration  of  the  intertace  into  Point- 
to-Muliip<)int  mode  This  mode  of  operation  leads  to  high  overhead  bccau-sc  of  the  requirement  to  maintain  an 
adjacency  pa  if- wise  between  nodes 

The  wireles,s  interface  type  reduces  the  amount  of  overhead  used  to  distribute  routing  information.  In  Point-to- 
Muitipomt  nK>de  (the  only  other  OSPFv2  configuration  appnpriate  for  a  wireless  niultihop  subnet),  each  router 
mast  form  an  adjacency  with  every  other  router.  Because  every  router  must  fojnn  a  full  adjacency  and  synchronize 
Its  databases  with  every  other  rouicr  in  Poini-to-Multipoint  mode,  the  overhead  grows  at  an  exponential  rate  as  more 
rKvfcs  are  added  to  the  network  Eurthermore.  iraditiona!  OSPF  uses  a  reliable  flooding  algorithm  to  distribute  link 
sute  asKertiscmcils  ( I  S  A.»)  through  the  network.  In  contrast,  the  wireless  interface  type  docs  not  require  full 
adjacencies  between  routers,  and  uses  an  optimized,  unreliable  flfioding  algorithm  for  efficient  I  SA  distribution. 

When  using  the  wireless  interface,  wc  expected  up  to  an  order  of  magnitude  reduction  in  the  amount  of  overhead 
generated  (when  compared  to  the  Point  to- Multipoint  nwxle).  without  a  significant  decrease  in  the  packet  delivery 
ratio  perfonnaniT 

7_3.l.2  Lipeiimeni  equipment  and  coafiKuration 

I  he  expenment  requires  the  use  of  16  routers  and  a  network  emulator  Rather  than  use  16  physical  routers,  we 
used  16  virtual  routers,  each  hosted  on  a  physical  router  using  the  VMware  product  for  virtual  machine  hosting 
Specifically,  four  physical  machines  hosted  16  virtual  routing  processes,  as  if  there  were  four  physical  machines 
pfes<-ni  for  each  actual  machine  I  he  ( fSPI  configuration  was  that  of  a  single  .subnet  (single  area,  single 
auionooKius  system) 

I  he  network  emulator  t  Boeing  Synthetic  Network  I  nvironment-SM  -  described  in  Section  4)  provided  an 
cmul.iicd  nmllihop  radio  environment  based  on  a  prcconfigurcd  mobility  script.  Wc  used  a  centralized  version  of 
the  emulator,  supported  by  16  fast  Ethernet  ports  on  a  l.i''ux  basi-d  bndge.  Tlic  mobility  scrip's  were  designed  to 


/tving.  N  and  W  Li.  "An  Integrated  Environment  for  Testing  Mobile  Ad  Hoc  Networks."  Proceedm^^  of  ACM 
Mohilhx  Conferem  r.  2(K)2  (Available  on  line  af  htrp  '  www  wins  hrl.com'pcople'ygz'papers  mohihocO.h  himl) 
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suitably  stress  the  touting  protocol  Al^ough  the  routers  were  connected  via  Eihenwi  to  the  wireleiai  emulator,  tlic 
router  inierfaccs  were  conf  gurcd  as  cither  Point-io-Multipoint  or  wireless  OSPF. 

To  test  the  ability  of  the  routers  to  deliver  usir  traffic,  each  node  generated  a  UDP  packet  and  sent  it  to  each  other 
node  tn  the  emulation,  once  per  second.  Assuming  this  is  a  minimal  10  byte  packet,  this  re-wlied  in  a  rtmgh 
mammum  of  I6*15*(40  10)*8  =  100  Kh/s  of  traffic  generated.  The  bandwidth  of  the  emulated  wireless  channel 

was  not  artificially  restncied  by  the  emulator 

F  igure  %%  illustrates  the  equipment  configuration  In  addition  to  tlic  Linux  routers  ami  the  emulator,  we  used  an 
additional  display  to  provide  visualization  of  the  demonstration 

Each  router  runs  OSPF 
and  sends  data  traffic  to 
every  ulhcr  rtailcr 


Figure  7-i  IJemi^nsiralion  lonfiguraiton  fur  Htreirss  network  emulaitir 
■’J.l.?  I>emonstralion  procednres 

Prior  in  the  dcmoristralioti,  we  gcneralcii  120-six<md  niobiliiy  svcnarios  for  llic  lest  configuration.  The  first 
dcmnnstraimn  coastsied  of  operation  in  legacy  OSPF  (Point-to-Multipoint  mode).  The  f)SPF  daemons  were  first 
started  on  each  rr'uter  Next,  the  emulation  senpt  was  executed  Following  completio.i  of  the  emulation,  data  was 
gathered  from  each  router,  priKcsscd.  and  the  results  visually  displayed.  After  finishing  of  the  Point  to  Multipoint 
confiifurafutn.  the  OSPF  dai-mons  were  restarted  in  wireless  OSPF  mode,  and  the  above  demonstration  was  re-nin. 

7  J.  1 .4  .Metrkf  and  data  eoliccliaa 

I  lx  two  nictnes  that  were  displayed  were  tPUtmg.p.rciocpi  overhead  and  dehvery  atjg. 

Kv'upiig  piotovol  yvi^lwad  c*  "inis  all  f>SPF  packets  sent  aiio  the  viuiiuicl,  including  a  bicakdown  between  unicast 
and  multicast  link  layer  hames  Ihe  overhead  was  determined  by  countuig  the  total  number  of  bytes  and  packets 
sent  during  the  emulation,  divided  by  the  number  of  seconds  of  emulation.  The  number  of  packets  sent  was  counted 
I't!  each  iK'de  using  icpdump  and  shell  and  Perl  scripts  Spctifically,  during  the  conduct  of  the  demonstration,  each 
node  performed  a  tepdump  on  packets  sent  on  its  wireless  interface  Upon  the  end  of  emulation,  the  tcpdunip 
lermmaied  and  senpts  automatically  ran  to  post-process  the  packet  dumps  and  extract  the  desired  sialisiks  These 
staiistifs  were  queried  for  from  the  master  emulator,  which  displayed  them  in  a  graphical  tormal. 

Packet  dcliycQ'  ratjo  wa.s  defined  as  the  total  number  of  packets  succevsfully  received  by  the  routers,  div  ided  by 
the  number  sent.  Packet*  sent  into  the  network  were  either  be  delivered  successfully,  or  were  dropped  due  to  a  lack 
of  route  Kt  the  destination,  or  were  dropped  due  to  a  loss  on  the  link  F.ach  router  kept  court  of  the  number  o 
packet*  th.,1  It  received  frotti  each  of  its  peers  At  the  end  of  the  emulation,  the  master  emulator  quened  each  node 
for  the  packet  reception  counts,  and  displayed  the  results  in  a  graphical  formal. 

7  Jt.  1  .S  IhemoiMtration  result* 

As  expected,  we  observed  that  the  overhead  performance  of  w  ireless  OSPF  was  hetwwn  that  of  Oil  SR 
with  Pomt-fo-Multipoini  interfaces  In  our  16-nodc  demo,  we  observed  roughly  lb  Kb’s  of  overhead  for  f>J  ■ 
Kb  s  of  overhead  for  wireless  OSPF.  and  <)2  Kb's  for  OSPF  Point  to-Multipomt  The  packet  dcliv^y  was  slightly 
hieher  f.  r  wireless  f  ISPF-  also  expected  During  the  actual  ifcmonstration.  one  unexpected  result  tws  that  the 
wireless  ( »SPF  overtiead  wa.s  higher  than  what  we  had  observed  the  previous  day.  and  highr.  than  what  we  had 
.diserved  in  simulations  After  the  demonstration,  wc  tracked  this  discrepancy  to  a  bug  in  the  implementation  and 
fixed  It  Section  S-2  above  shows  the  results  of  our  final  implementation  testing 


Multiple  virua!  machines 
h.isic-d  on  single  physical 
machine  (  .i  virtual  machines) 


Wirrie**  Mtworb  emulator 
(aaodified  Ethernet  bridge) 


S.  vemb-f  ?  1  2irfi^ 


Page  4b  of  48 


the  Hoemg  Company 


7  J.2  DM'P  umI  wirciris  routiig  iategrttion  (Sub-drmo  2) 

I  hf.  ifcinon^traiion  was  clesigncd  to  show  the  operatinnaf  benefit  of  DSCP-capablc  dynamic  routing,  and  to  show 
ihc  miegratiim  of  the  DSCP  and  wireless  extensionK  to  OSPF. 

1X1. 1  Objective  and  expected  resaltx 

We  expect  to  show  the  following  results  with  this  demonstration: 

•  DSCP-ba«;d  dynamic  routing  allows  for  load  balancing  across  satellite  finfe  with  asymmetric  bandwidth, 
in  a  manner  that  allows  for  dynamic  failover  to  alternate  paths  siwuld  the  primaiy  path  ibr  a  class  ol  tratlic 
fail: 

•  DSC  P-bwd  routing  is  interoperable  with  DSC  P-based  packet  scheduling  on  congested  links:  and 

•  DSCP  based  routing  and  w  ireless  OSPF  extensions  arc  interoperable. 

We  will  repeat  our  demonstration  conducted  at  SPAW  AR  in  May.  2003,  with  three  extensions.  I  he 
demonstration  in  May  showed  how  JCA  traffic  could  be  priority  routed  over  notional  Challenge  Athena  links,  and 
that  fallback  paths  were  tn  place  to  route  (and  priority  schedule)  the  JCA  traffic  over  line-of-sight  wireless  links  if 
the  satellite  connectivity  to  a  particular  ship  completely  failed  The  three  extensions  to  this  demonstration  arc  as 
follows 

( il  we  will  illustrate  successful  operation  of  this  capability  through  in-line  packet  encryptors; 

( il  i  we  will  show  succcssftil  "mixed-mode"  operation  using  AS-cxternal  ISAs  fa  feature  that  was  not 
implemented  m  May.  200?);  and 

( III )  we  w  ill  replace  the  point-Kvpoint  link  between  ships  with  an  emulated  wireless  muPihop  network. 

7.3.2.2  Kxpcnmenl  equipment  and  roofiguration 

We  will  Use  the  subset  of  the  integrated  demonstration  configuration  (Figure  7-21  shown  in  Figure  7-4.  As  Figure 
■^-4  itiusiratcs.  the  demonstration  will  require  six  Boeing  routers  (additional  wireless  routers  may  be  added  via 
virtual  machines),  two  C  isco  routers,  three  encryptors.  and  six  traffic  sources  and  sinks.  The  links  will  be  composed 
of  I  ihemct  segments,  two  satellite  simulators,  six  serial  RS44d  connections,  and  a  wireles,s  network  emulator. 


lo  -r 


TW  f  4timnaTiv 


triifnc  uak  Iriffic  link 


Hgure  7-4  Dt-mumiiaiion  t  onfiguriition  for  "DSCl’  und  H'iivless  Routing  InU'gralion  “ 

he  nuehincN  will  be  eonfigured  as  fnllowN 

•  JCA  IrafTic  Murces  and  sinks.  These  I  mux  machines  will  generate  long-running  TCP  connections 
flowing  from  the  JCA  source  to  the  JCA  sinks  on  each  ship.  The  T  CP  connections  will  be  marked  with  a 
selected  OSCP  value 

•  Traffic  source  and  sinks,  T  hese  1  mux  machines  will  generate  and  consume  test  traffle  with  DSCP  values 
diflerent  from  the  value  used  for  JCA  trafTic. 

•  .Network  management.  This  Linux  machine  will  also  serve  as  a  network  management  workswtion  with  a 
graphical  depiction  of  the  network  topology. 

•  Fneryptor.  These  Linux  machines  will  perform  packet  encryption  similar  to  T  ACI.ANF.  cncryptors 

•  U'irelcss  network  emulator.  This  machine  will  provide  emulation  ('f  a  multihop  radio  environment. 

•  Satellite  simulator.  T  hese  machines  will  provide  delay  and  bandwidth  emulation  bctw'cen  routers. 

•  Cisco  routers,  i  hese  routers  will  connect  the  JCA  traffic  source  to  tin:  rest  of  the  network  using  BGP  and 
route  redistribution  inlo  DSl'T. 

•  Linux  routers.  These  routers  w  ill  be  the  focus  of  the  demonstration.  Each  will  run  an  instance  of  OSPl 
routing  with  DSCP-based  and  wireless  extensions  The  DSCP  extensions  will  permit  the  setting  of  link 
metnes  cn  a  pcr-DSCP  basis,  thereby  influencing  the  packet  flows  for  different  DSCP  classes.  I  he 
wireless  exieriMOPs  will  operate  efficiently  over  the  wireless  multihop  network.  In  addition,  standard  Linux 
traffic  controls  will  permit  prionty  queuing  techniques  on  the  basis  of  DSCP. 
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7J.2.3  Demomtruioa  prorediim 


All  ot'ihe  Linux-ba'scd  OSPF  prtKCSses  will  be  configured  to  (operate  in  "mixed-mode”  operation,  which  means 
that  they  will  be  able  to  compute  DSCP-cnahled  routes  despite  the  presence  of  non  DSC'P-capable  routers  (C^isco)  in 
the  path  I  he  following  steps  will  j>c  taken  to  set  up  the  demonstration: 

(i>  confisure  the  packet  encryptors  for  encrypted  tunnels  (JCA  source  to  JCA  sinks),  ffltd  configure  the  cncryptors 
to  pass  the  DSCP  value  through  to  the  tunneled  outer  IP  header: 

(ti)  configure  traffic  sources  to  generate  flows  with  desired  DSCP  values: 

tiiij  configure  link  metrics  on  Linux-based  routers  to  preferentially  route  emulated  JCA  trafik  over  C'hallengc 
Athena  links,  artd  other  traffic  over  SHF  links,  with  fallback  routes  via  ship-to-ship  link.s; 

(tv)  crxifigure  pnority  queuing  on  satellite  interfaces  such  that  JCA  traffic  is  served  at  higher  priority  than  other 
traffic  when  the  queue  is  congested;  and 

|v)  configure  ihc  wireless  network  emulator  to  provide  a  multihop  wireless  cnvintninent. 

1  he  demonstration  will  first  illustrate  the  correct  routing  (load  balancing)  of  JCA  traffic  and  other  traffic.  Next, 
the  Challenge  Athena  satellite  link  will  be  brought  down  to  ship  1.  and  JCA  traffic  will  be  rerouted  to  the  SHF  link 
to  ship  1  Next,  tlie  SHF  link  to  ship  1  will  be  brought  down,  forcing  the  JCA  traffic  to  be  rerouted  m  ship  ?,  and  via 
the  wircks.s  network  to  .ship  I  The  satellite  bandwidth  to  ship  2  at  this  point  will  be  oversub-scribed,  with  the  result 
that  JCA  traffic  will  receive  higher  pnonty  over  the  congested  links.  The  satellite  links  will  be  restored  in  reverse 
order,  with  the  resulting  routing  rcrovering  to  the  original  state 

7J.2.4  .Metrics  and  data  collection 

I  hi  ti-stlx'd  will  be  instrumented  with  packet  sniffing  proces.sis  (tepdump)  on  key  interfaces  in  the  topology. 

Using  these  tools,  in  combination  with  a  graphical  utility  for  displaying  DSCP-based  traffic  flows  on  an  interface 
(shown  in  Figure  7-5),  we  can  display  the  operation  of  the  protocol  in  real-time,  and  will  verify  the  correct  routing 
by  inspection  of  packei  traces 


Figure  7-5  I'vsuuhzunon  of  irqftii  flow  on  a  link,  baaed  on  DSCP  value 
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7,3.3  Liik-16  range  extennon  (SutMiemo  3) 

I  his  demonstration  is  designed  to  show  the  operational  benefit  of  multicast  DSCP-capab'.e  d>’namic  routing,  in  the 
context  of  future  use  by  enhanced  Command  arid  Control  Processors  (C2P)  used  for  range  exten-sion  of  Link- i  6 
networks  over  ADNS. 

7.3J.1  Objective  and  expected  results 

I  he  NBN  "Battlcforcc  Composite  Networking”  program  is  building  a  Link- 1 6  range  extension  capability,  to 
enable  L.ink- 16  tracks  to  be  sent  to  other  enhanced  Command  and  Control  Processors  (C2P)  over  the  AONS  system 
Since  the  prototype  C'2Ps  with  11*  interfaces  arc  mvi  yet  ready,  we  will  use  surrogate  C7Ps  (i.inux  computers  with  a 
multicast  appIicat:on)  for  this  demonstration. 

A  ke%  component  of  this  system  will  be  the  use  of  QoS  capabilii.es  in  Cisco  routers  to  handle  this  high  priority 
traftie  floi*'.  In  our  demonstration,  wc  will  show  how  DSCP-based  multicast  routing  can  help  to  preferentially  route 
traffic  along  certain  network  paths 

7  JJ.2  Experiment  et|uipinent  and  cunfiguration 

'ke  will  use  the  subset  of  the  integrated  demonstration  conliguraiion  (figure  7-2)  shown  in  figure  1-t.  As  figure 
7-6  illustrates,  the  demonstration  will  require  six  Boeing  routers  (additional  wireless  routers  may  be  added  via 
virtual  machines),  and  four  traffic  sources  and  sinks.  The  links  will  be  composed  of  F.tncmct  segments,  two  satellite 
simulators,  six  senal  RS449  connectioas.  and  a  w'irclcss  network  emulator.  The  emulated  (,'2P  machines  are 
connected  to  .\DNS  routers  at  llic  (notional)  ficciel  level. 


hpirf  fiemonsiruiinn  ronfigtiraii'm  for  "I ink  Ifi  Rangr  Kxtrnsinn.  " 
The  machines  will  be  configured  as  follow  s: 
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•  C2f  MrrofMt.  These  are  Linux  machines  nmning  video  softv^are  (vkIto  serves  as  a  amogate  for  I.mk-lo 
nracks).  The  C2P  surrogate  on  ship  2  will  orieinate  multicast  video  datagrams,  marked  with  a  specific 
DSCP  value,  that  will  be  delivered  to  the.  receivers  on  .ship  I  and  ship  .1. 

•  Network  Buaagcment.  This  Linux  machine  will  also  serve  as  a  network  management  workstation  with  a 
graphical  depiction  of  the  network  topology. 

•  Wireless  actwork  emulator.  This  machine  wall  provide  emulation  of  a  roultihop  radio  environment. 

•  Salellile  Emulator.  These  machines  will  provide  delay  and  bandwidth  emulation  between  routers. 

•  Linus  routers.  These  routers  will  be  the  focus  of  the  demoastration.  Each  will  run  an  instance  of  OSPF 
routing  with  l3SC'P-faased  and  wireless  extensions  The  DSCP  extensions  will  permit  the  setting  of  link 
metrics  on  a  per-DSt?P  basis,  thereby  influencing  the  packet  flows  for  different  DSCP  cla^s.  The 
wirclcs.s  exteasions  will  operate  efficiently  over  the  wireless  multihop  network.  In  addition.  Mandard  Linux 
traffic  controls  will  permit  pnonty  queuing  tcchmques  on  the  basis  of  DSCP. 

7..T..T.3  Demonsiratiou  procedures 

The  following  steps  will  be  taken  to  set  up  the  dcracastration: 

ill  configure  the  i  2P  surrogate  application  to  generate  flows  with  the  desired  DSCP  value: 

<ul  configuiv  link  iiieUii.s  on  Linux-based  rouieis  to  picfciciitially  route  emulated  C2P  liaflFic  fiisf  over  wircie.ss 
links,  then  second  over  Challenge  Athena  links,  while  other  traffic  off  ship  uses  SHE  links; 

tail  configure  the  wialess  network  emulator  to  provide  a  multihop  wiaiess  environment. 

The  demonstration  will  first  illustrate  the  multicast  traffic  using  the  multihop  wireless  network  for  video 
distribu'ion  Next,  the  link  from  Ship  1  to  the  rest  of  the  wiielcs.s  network  will  be  brot.ea  At  this  point,  multicast 
frames  will  additionally  flow  over  Challenge  Athena  links  to  .Ship  1. 

‘t..i..3.4  Metrics  and  data  collection 

fhe  testbed  will  be  mstrumcnied  with  packet  sniffing  processes  (tepdumpi  on  key  interfacc,s  in  the  topology,  and 
DSCP  irJiTs.  moritors  such  as  shown  above  in  Figure  5-1.  This  demons!'  alion  is  more  a  demonstration  of  capability 
lather  than  perf  ormance  metrics  so  no  specific  performance  naefnes  will  be  collected  for  this  expenment 
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7.3.4  Mobik  platform  (Sub-deoio  4) 

This  demonstration  is  designed  to  show  the  operational  goal  of  mobile  platforms  being  supported  by  wireless 
OSPI  routing. 

7J.4.I  Objective  and  expected  results 

I  bis  demonstration  will  show  a  mobile  router  with  an  associated  subnet  roaming  from  one  network  to  another  A 
host  on  the  mobile  platform  shall  communicate  with  a  fixed  node  in  the  infrastructure.  The  router  detects  when  it 
enters  the  new  subnet,  configures  its  new  IP  address  (obtained  in  an  authenticated  fashion  by  DHCP),  restarts  or 
reconfigures  the  OSPf  daemon,  starts  advertising  the  attached  subnet  in  its  new  wireless  subnet,  and  data  transfer 
starts  flowing  again  between  the  host  on  the  mobile  platform  and  the  host  in  the  fixed  infrastructure.  The  purpose  is 
'  w  how  wireless  OSPF  can  support  transit  operation  of  mobile  platforms. 


7_V4.2  .  Experiment  equipment  and  configuration 

We  w  ill  u-sc  the  subset  of  the  integrated  demonstration  configuration  (Figure  7-2)  showm  in  Figure  7-7.  As  Figure 
7-7  illustrates,  the  demonstration  will  require  five  Boeing  routers  in  ihe  fixed  infra.struciure.  and  a  number  of 
physically  mobile  routers!  One  mobile  router  wnll  be  hosting  a  subnet  with  a  Linux  traffic  source  and  sink,  which 
can  talk  to  hosts  on  each  of  the  notional  ships.  Citlicr  mobile  routers  will  include  PDAs  and  lapto()s  with  802  1  lb 
interfaces  The  links  wall  be  composed  of  two  802.1  Ih  subnets.  F.ihemct  segments,  and  a  wireless  network 
emulator 


wirelfis  iubnrt  I  wirtltM  .tuhner  2 


hflure  7-  7  Dtmon^irititun  amfiguraiion  fur  "Mohile  Platform  " 

I  he  machines  will  be  configured  as  follows 

•  I  raffle  vuurcrs  and  vinhv.  fhesc  are  I  mux  maelimes  running  traffic  generation  programs  suc.)i  as  NRI 
.M(.l  N 
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•  Wirekw  actwork  emulator.  This  machine  will  provide  emulation  of  a  oiuliihop  radio  Kivironraent. 

•  SmelUte  simulator.  These  machines  will  provide  delay  and  bandwkiih  eimilation  beti^n  routers 

•  Linux  routers.  I  here  will  be  a  number  of  different  I.inux -based  routers  in  the  demtMistration,  including 
Dell  rackmount  and  de.sktop  servers,  laptops,  and  PDA-s  (Cotnpaq  tPAQ),  each  ninning  an  iretance  of  the 
wireless  OSPF  daemon.  In  wireless  subnet  I ,  the  fixed  router  will  ato  s«^  as  a  DHCP  server,  and  the 
mobile  platfonn  will  run  DHCP  client  software. 

7  J.4  J  Demoustratioa  procedures 

To  set  up  dw  dcmon.straiion,  wc  will  configure  devices  on  wireless  subnets  I  and  2,  mcluding  102  I  lb  channels, 
IP  addressing,  and  routing  protocol  daemons.  On  the  mobile  plaform,  the  wireless  router  will  advertiw  reachability 
to  the  IP  subnet  hosting  the  traffic  source.  The  wired/ wireless  router  on  subnet  I  will  he  ccnfigiued  to  serve  a.s  a 
DHC  P  server 

The  mf'bilc  platfonn  will  initiate  a  lonp-ninnmg  data  transfer  with  a  uaffic  sink  on  ship  2.  Next,  the  mobile 
platform  will  he  taken  out  of  range  of  wireless  siibnet  1  (cither  physically  out  of  range  or  by  teconfigur.ng  die 
H02  1  lb  channel  of  operation),  and  into  range  of  subnet  2.  1  he  router  will  acquire  a  ikw  IP  address  in  an 
authenticated  manner,  using  cryp!»>graphit  techniques  for  DHCP  found  in  RFC  .1118.  Upon  obtaining  new  IP 
configuration  for  the  new  wireless  subnet,  the  router  wilt  begin  to  advertise  reachability  of  the  subnet,  and  the  data 
transfer  heiwecn  the  Uaffic  source  and  sink  will  resume  once  the  routing  converges. 

7..1.4.4  Metrics  aad  data  coilcctioB 

TIu'  key  mcuic  for  this  demonsiraiion  will  be  ri)UtHig.cpnv5rgeiKe  liffle.  defined  as  the  lime  fmiH  which  die 
mobile  router  acquires  a  new  IP  address  ici  the  lime  at  which  IP  routing  is  stable  enouyt  for  the  data  transfer  to 
resume  We  will  c.stimate  ihcs  by  conducting  tepdumps  on  key  interfaces  in  the  topology,  which  will  time.siamp  the 
significant  events  in  this  demonstmtum 


■  It  I  bums  and  W  Aro  iugh.  "Autheniicaiion  lof  HI  H  P  Messages.”  Internet  RetpuU  ferC  omments  (RFC!  11 18. 
June  2««H .  available  on-line  at  http  w  w-w  letf  erg  Tfc  rfc  1 1 1 8  txl 
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Host  ioinini;  and  authentication  (Sub-demo  5) 


I  his  demonstrarion  is  designed  to  show  the  operational  goal  of  mobile  hosts  being  supptttleH  by  w  ireless  DSPF 
routing  and  authenticated  DHCP,  and  how  data  tratllc  can  be  authenticated  and  encrypted  on  an  end  to-end  basis. 

7  J.S.  I  Objective  and  eipected  results 

This  demonstration  will  show  a  mobile  router  with  an  active  TCP  connection  to  a  host  in  the  fixed  infrastructure, 
a.s  It  changes  subnets,  readdresses  its  interface,  and  continues  to  use  its  TCP  connection  with  the  remote  host  despite 
the  readdressing.  This  demonstration  combines  the  wireless  OSPF  routing  with  the  Host  Identity  Protocol  (HIP),  a 
proposal  under  consideration  at  the  ll!Th  as  a  new  approach  to  host  mobility,  multihoming,  and  authentication  I  he 
purprise  is  to  show  how  wireless  OSPF  can  be  u.sed  in  a  network  context  that  allows  for  hosts  to  join  networks  in  an 
authenticated  manner,  with  all  traffic  encrypted 

7  J.S.2  Kxperiment  equipment  aud  configuration 

1  his  configuration  (shtiwn  in  Figure  5-6)  is  essentially  the  same  as  shown  above  in  Figure  5-5,  but  with  a  mobile 
host  (wireless  laptop)  used  in  place  of  a  mobile  platform.  A.s  Figure  5-6  illustrates,  the  demonstration  will  require 
five  Boeing  routers  in  the  fixed  infrastnicture,  and  a  number  of  ph>’Sica)ly  mobile  routers.  One  mobile  router  will 
also  be  a  host  that  talks  to  a  hf>st  on  one  of  the  .ships  Other  mobile  routers  will  include  PDA.s  and  laptops  with 
802  1  lb  interfaces.  The  links  will  be  composed  of  two  M02.nb  subnets,  tthemet  segments,  and  a  wireless  network 
emulator 


-Wre/ess  »«An<r  /  wirelm  nufmrt  2 


Fii^urc  '  I  Ofmnnstralionionfif’uratum  for  "Host  Joining  cmii Aulhcnticalion 

*  R  Moskowii/.  P  Nikandcr.  and  P  Jokcla,  •  Host  Identity  Protocol."  Inicmel-Draft:  draft  moskowitz  hip-7, 

rtvailahlc  on-line  at  http  w-ww  lelf  <irg  mlemei  drafts'draft-mnskowitz-hip-O?  txl 
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7J.S  J  OcmoMtrsiMHi  procedures 

lo  SCI  lip  the  demonsiiaiion,  we  will  configure  devices  on  wireless  subnets  I  ud  2,  uicluding  K02ri  I  b  ehoniwls, 
IP  addressing,  and  routing  protocol  daemons  T  he  wired  wireless  router  on  subiKt  1  will  be  configured  to  serve  an  a 
DHCP  server. 

The  mobile  host  will  first  initiate  a  data  connection  to  a  host  on  ship  I  or  2  using  die  Host  Idimlitv  Payload  (HIP), 
ih*'  will  consist  of  a  HIP  protocol  handshake,  based  on  public  key  cryptography,  that  will  establirfi  session  keys  for 
the  TCP  connection  w  use  IPscc  encryption  Next,  the  rnobile  host  will  be  taken  oat  of  range  of  wwetess  subnet  1 
(either  idiysically  wit  of  range  or  by  reconfiguring  the  802. 1  lb  channel  of  operauon).  and  mio  range  of  subnet  2. 

Ihe  host  will  firta  acquire  a  new  IP  address  tn  an  authentKated  manner,  using  cryptografdiic  lechnu|iKs  for  DHf  P 
found  in  RFC  3118.  Upon  obtaining  new  IP  configuration  for  the  new  wireless  subnet,  the  hort  will  next  signal  to 
the  etwesponding  host  (using  HIP  Readdress  protocol)  that  it  has  changed  its  IP  address.  TIk  HIP  proti>col  allows 
the  remr  te  host  to  authenticate  the  wireless  ho  I  and  confirm  that  the  host  is  indeed  the  same  host  but  at  a  different 
address  After  this  liandshake.  encrypted  communication  between  the  hosts  will  lejaime. 

yj.5.4  Metric*  and  data  collection 

I'his  demonstration  is  focused  on  illustrating  the  capability  of  using  HIP,  ui  conjunctitm  with  wireless  OSPF 
luuting,  to  perform  secure  1k>sI  mobility  in  a  tactical  environment.  The  corrctl  operation  of  HIP  will  be  observed  by 
luspection  of  data  transfer  windows  on  the  laptop  and  fixed  host 
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8  Summary' 

()ur  NBN  Composite  Routing  program  has  delivered  modificatioas  to  the  standard  OSPFv2  routing  protocol. 
After  first  conducting  a  simulation  trade  study  of  routing  protocol  alternatives  for  future  NBN  networks,  we  decided 
that  OSPF  modifications  would  speed  the  technology  transition  of  mobile  ad  hoc  routing  protocols  to  commercial 
products  We  have  studied  under  simulation,  specified,  and  implemented  extensions  to  OSPFvZ.  and  have  validated 
the  implementation  performance  in  lab  testing  and  demonstratioas  The  results  of  this  research  program  arc 
promising,  and  we  are  working  with  other  groups  to  attempt  to  standardize  such  protocol  extensions. 

8.1  Technology  transfer  directions 

We  e.xpeci  that  OSPFv2  extensions  would  be  used  by  a  fubire  Navy  if  they  were  made  available  in  commercial 
products,  such  as  Tisco  routers  and  ffR  S  nidio/routcrs  The  main  focus  of  our  OKR  KSA  FNC  Block  2  program  is 
to  transition  a  wireless  ii.terfacc  capability  to  Cisco  routers  and  DSCP-based  routing  extensions  to  JTRS  radio 
software  Additionally,  standardization  of  such  extensions  would  facilitate  nw're  vendor  acceptance.  We  plan  to 
support  stardardi/aiion  efforts  under  the  Block  2  program. 

8.2  Future  work 

Wc  ihfiripate  that  the  following  topics  will  he  the  subject  of  future  work  in  this  efTort,  under  ONR  KSA  FNC 
Block  2  program: 

quanufying  projected  performance  in  future  expected  operational  scenarios,  including  the  handling  of 
similar  quantities  and  lypt^s  of  mtema!  and  external  OSPF  LSAs  found  in  Naval  afloat  networks. 

C'  identifying  key  parameters  to  study  for  sensitivity  analysis 

I  st>ecif>inu  how  the  estciisions  could  be  folded  into  OSPFvl  for  IPv6. 

c  recommending  how  the  extensions  fit  into  the  overall  Ck'S  framework  for  the  Navy,  including  wse  of 
network  •nanagement  and  yoS  policy  management  tools  such  as  Cisco  QoS  Policy  Manager 

c  siudving  cxicnsums  to  PIM  or  source  specific  multicast  pn>ii.cols  to  enable  dynamic  policy  based  rooting 
based  on  DSCP  or  other  similar  mechanisms; 

c  studying  possible  extensions  to  or  use  of  OSPF.  IS-IS,  or  EIGRP  to  sedve  scalability  concerns  relating  to 
the  cros-s-conneci  of  dif  ferent  At  'Rs. 

c,  combining  routing  protocol  extensions  with  MPLS  and  OSPF  traffic  engineering  extensions,  and 
c  consideration  of  interworking  issues  tor  more  seamless  joint  operatioas. 
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